Re: [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size [try #3]

[Andrew Morton <akpm@osdl.org>]

David Howells <dhowells@redhat.com> wrote:
>
> 
> > What's the attribute((pure)) for?
> 
> It tells gcc that the function's result only depends on its arguments... it
> makes no references at all to external data. It's like __attribute__((const))
> but stronger. This means that gcc can generate code that caches the result.

Of course, but we could use it in zillions of places and we don't.  Does it
actually help?

> > It generates a warning on older gcc - please use __attribute_pure__.
> 
> We still support gcc's that old?

yup.  And gcc-3.4 complains that log2() conflicts with an inbuilt function,
but you renamed it.

> > The other four or five implementations of log2() use ffx(~n).
> 
> Yes... but ffs() and ffz() take int args, not long args. I suspect that
> shouldn't matter (that would require the hash table to be calculated at 4Gig
> buckets in size or greater to be a problem), but why take the chance when we
> can avoid it easily?

No, ffz() takes an unsigned long argument.


It's still not clear to me why we cannot simply increase MAX_ORDER.  If
that exposes shortcomings in the buddy allocator, that should be where we
expend effort?