Thread (158 messages) 158 messages, 14 authors, 2008-06-17

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

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help