Date: Mon, 14 Jun 2004 04:04:17 -0700
From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Permit inode & dentry hash tables to be allocated >
 MAX_ORDER size [try #3]
Message-Id: <20040614040417.29e7497b.akpm@osdl.org>
In-Reply-To: <18241.1087210067@redhat.com>
References: <20040611150110.73fadefb.akpm@osdl.org>
	<567.1086950642@redhat.com>
	<6567.1086963705@redhat.com>
	<18241.1087210067@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1402
Lines: 37

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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/