Re: [PATCH] percpu: add optimized generic percpu accessors
From: Christoph Lameter <hidden>
Date: 2009-01-28 17:28:14
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2009-01-21 · Re: [PATCH] percpu: add optimized generic percpu accessors · David Miller <davem@davemloft.net>
- 2009-01-21 · Re: [PATCH] percpu: add optimized generic percpu accessors · Eric W. Biederman <hidden>
- 2009-01-21 · Re: [PATCH] percpu: add optimized generic percpu accessors · Stephen Hemminger <hidden>
- 2009-01-21 · Re: [PATCH] percpu: add optimized generic percpu accessors · Eric W. Biederman <hidden>
- 2009-01-21 · Re: [PATCH] percpu: add optimized generic percpu accessors · Ingo Molnar <hidden>
On Wed, 28 Jan 2009, Rusty Russell wrote:
AFAICT we'll need a hybrid: HAVE_NMISAFE_CPUOPS, and if not, use atomic_t in ftrace (which isn't NMI safe on parisc or sparc/32 anyway, but I don't think we care).
Right.
Other than the shouting, I liked Christoph's system: - CPU_INC = always safe (eg. local_irq_save/per_cpu(i)++/local_irq_restore) - _CPU_INC = not safe against interrupts (eg. get_cpu/per_cpu(i)++/put_cpu) - __CPU_INC = not safe against anything (eg. per_cpu(i)++) I prefer the name 'local' to the name 'cpu', but I'm not hugely fussed.
The term cpu is meaning multiple things at this point. So yes it may be better to go with glibc naming of thread local space.