Re: [patch 04/41] cpu ops: Core piece for generic atomic per cpu operations
From: Rusty Russell <hidden>
Date: 2008-06-12 02:44:33
Also in:
lkml
From: Rusty Russell <hidden>
Date: 2008-06-12 02:44:33
Also in:
lkml
On Thursday 12 June 2008 10:58:01 Nick Piggin wrote:
On Thursday 12 June 2008 09:39, Christoph Lameter wrote:quoted
On Wed, 11 Jun 2008, Rusty Russell wrote:quoted
quoted
4. The modeling of local_t on atomic_t limits it to 32bit!Again wrong. And adding an exclamation mark doesn't make it true.Ewww ... Its atomic_long_t ahh. Ok then there no 32 bit support. What about pointers?sizeof(long) == sizeof(void *) in Linux, right? If you were to support just a single data type, long would probably be the most useful. Still, it might be more consistent to support int and long, same as atomic.
Sure, but in practice these tend to be simple counters: that could well change when dynamic percpu allocs become first class citizens, but let's not put the cart before the horse... Per-cpu seems to be particularly prone to over-engineering: see commit 7ff6f08295d90ab20d25200ef485ebb45b1b8d71 from almost two years ago. Grepping here reveals that this infrastructure is still not used. Cheers, Rusty.