Re: [RFC][PATCH 2/5] mm: Switch mod_state() to __this_cpu_read()

[Christoph Lameter]

On Tue, 20 Sep 2011, Thomas Gleixner wrote:

> > Why would there be a warning triggered? this_cpu_read should take care of
> > disabling preemption for the read if needed. In fact the fallback case
> > does do exactly that.
>
> And what exactly is the purpose of having a preempt_disable()/enable()
> pair in this_cpu_read()?

It avoids a read from one cpu of another processors per cpu area. In the
fallback case the processor has to calculate the per cpu address and then
retrieve data from the calculated address. The process can be migrated
between calculation of the address and the actual fetch.

The more severe cases are the RMV operations like this_cpu_inc.

> functions we should add a more sensible debug interface like:
>
>   debug_check_percpu_access()
>
> and the per cpu sections which require protection over a series (1
> .. N) of this_cpu_* operations want to have
>
>   this_cpu_start()
>   this_cpu_end()
>
> or similar annotations around them.
>
> This allows us to do proper analysis of this_cpu usage and makes the
> code understandable.

Not sure what you want to check in this_cpu_xx operations. Why could
there be issues with this_cpu_xx operations?

I see that __this_cpu_xx operations may not work as intended in
preemptable contexts and there we could have more changes.

this_cpu ops are single instructions that do not guarantee any consistency
with other this_cpu_ops. If you want consistency (same per cpu area data)
then preemption needs to be disabled.

--
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/