> * Jesper Juhl (
jj@chaosbits.net) wrote:
> > On Sat, 30 Oct 2010, Mathieu Desnoyers wrote:
> >
> > > * Jesper Juhl (
jj@chaosbits.net) wrote:
> > > > Hi,
> > > >
> > > > We can optimize kernel/relay.c::relay_alloc_page_array() slightly by using
> > > > vzalloc. The patch makes these changes:
> > > >
> > > > - use vzalloc instead of vmalloc+memset.
> > > > - remove redundant local variable 'array'.
> > > > - declare local 'pa_size' as const.
> > >
> > > Hrm ? How does declaring a local variable as const helps the compiler in
> > > any way ?
> > >
> >
> > Hmm, probably not very much in this case (but it doesn't hurt either ;) -
> > actually, removing the const yielded the exact same result, so it's
> > "not at all" in this case).
> > That bit came from my "build-in" tendency to declare stuff const when it
> > obviously doesn't change/nor should. It's a habbit..
>
> Which looks to me like a misunderstanding of the C99 standard. What you
> do is:
>
> static struct page **relay_alloc_page_array(unsigned int n_pages)
> {
> const size_t pa_size = n_pages * sizeof(struct page *);
> ...
> }
>
> So the compiler has no choice but to emit code that will fill in the
> value of pa_size at runtime, because it depends on "n_pages", a
> parameter received by the function. So pa_size is everything but
> constant.
>
> The C99 standard, section 6.7.3 (Type qualifiers) states:
>
> "The implementation may place a const object that is not volatile in a
> read-only region of storage. Moreover, the implementation need not
> allocate storage for such an object if its address is never used."
>
> So maybe gcc is kind here and it just removes this const specifier
> without complaining, but a different compiler might be more strict and
> fail to compile because you would be dynamically assigning a value to a
> variable placed in read-only storage.
