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

[Christoph Lameter]

On Fri, 23 Dec 2011, Linus Torvalds wrote:

> You have two cases:
>
> Case 1: you actually know what CPU you are on, and the number may have
> some meaning. But in that case you are also *pinned* to that CPU, and
> there is no difference between
>
>    x = percpu_value;
>    x += y;
>    percpu_value = x;
>    .. look at 'x' .. to see what you did
>
> and
>
>     percpu_value += x;
>    ..look at percpu_value to see what you did ..
>
> and
>
>     x = xadd percpu_value,y
>
> so there are no "atomicity advantages" - xadd is the same as
> open-coding it. You are pinned to the CPU, all three ways are 100%
> equivalent.

As mentioned before the main point of the use of these operations (in the
form of __this_cpu_op_return) when the cpu is pinned is to reduce the
number of instructions. __this_cpu_add_return allows replacing ~ 5
instructions with one.

These operations are used in f.e. in vm statististics that have to scale
well and have the lightest possible impact on the rest of the vm code.

"atomicity advantages" were never claimed to exist for the __this_cpu_xx
operations.

>> The other case is:
>
> Case 2: you're not pinned to the CPU, and you just do statistics and
> add some value to memory. BUT NOW THE RESULT HAS ABSOLUTELY NO
> MEANING!
>
> Now "xadd" would possibly give different results from "add and read
> the result", since you migth be moving around between cpu's, but there
> is absolutely no way you could ever care, sine the value you read back
> is meaningless regardless of whether it's the return value of xadd, or
> the value from some other CPU. There are other cpu's with the same
> percpu variable, and they are all equivalent as far as you are
> concerned, because you're not pinned to one of them.

You would care if you had special actions that have to be triggered on all
processors if for example a threshold was breached on a single processors
counters (and one would fold all differentials into a global counter) or a
per cpu counter reaches zero (and one would need to replenish lists of
objects or some such thing). In that case it matters that the operational
result be checked later regardless of the cpu we are on right now.

There are no use cases of the this_cpu_xx_return operations as far as I
can see so we could remove those.

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