Re: [GIT PULL] slab fixes for 3.2-rc4

[Christoph Lameter <cl@linux.com>]

On Tue, 20 Dec 2011, Pekka Enberg wrote:

> To illustrate the issue, for "per cpu add" we have:
>
> __this_cpu_add()
> this_cpu_add()
> irqsafe_cpu_add()
> percpu_add()
>
> Why do we need all of them?

These are all operations that frequently occur in hot paths of the OS.

On x86 all variants map to the same instruction. These will be issueing
exactly one ASM instruction that is therefore irqsafe and preempt safe.
The single instruction will perform the relocation of the pointer relative
to the current cpu area and then perform the RMV operation without the
cost of an atomic operation.

For non-x86 we have the issue that typically separate instruction have to
be used to perform the relocation relative to the current per cpu area and
the RMW operation. The problem is that an interrupt or reschedule
operation can occur between the address calculation and the RMW operation.
The RMW operation may occur on the wrong processors per cpu
data. So we need some way of preventing the change of processors or
interrupts.

The __this_cpu_add() variant simply does nothing to prevent this. Just
assumes that the caller has taken a lock or disabling interrupts that
provides sufficient measures to prevent the rescheduling on a different
processor.

The this_cpu_add() variant disables preemption, then does the operations
and then reenables preemption. This is usually sufficient since most per
cpu data is not accessed from an interrupt context.

The irqsafe_cpu_add() variant disables interrupts, does the operations and
then reenabled interrupts. It is needed if counters etc are modified from
an interrupt context.

percpu_add() is an older variant of the per cpu operations that is (or
was?) x86 specific. this_cpu_xxx() operations are used in core code.