Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write()

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Tue, 2011-09-20 at 14:12 -0400, Mathieu Desnoyers wrote:
> > Not quite. What I was proposing more precisely:
> > 
> > - this_cpu_*() for the case where the caller needs to disable
> >   preemption. This is the default case. This is exactly what you
> >   proposed, with WARN_ON debug checks. This could even be "percpu_*()"
> >   now that I think of it. There is no real point in the "this_cpu"
> >   prefix.
> > 
> > - preempt_protected_percpu_*() and irq_protected_percpu_*() for
> >   statistics/slub use. Those primitives disable preemption or irq
> >   internally on non-x86 architectures. The caller of these primitives
> >   is not required to disable preemption nor irqs.
> 
> This is totally confusing. It suggests to me that the percpu requires
> preemption protected. You are coupling the implementation of the
> function too much with the name. The name should describe its use. What
> does "preempt_protected" mean?  To me, it sounds like I should use this
> in preempt protected mode. Still way too confusing.
> 
> any_cpu_*() is still much more understanding. It means that we are
> manipulating a CPU variable, and we do not care which one.
> 
> Looking at the real use cases of this_cpu(), that seems to be exactly
> the use case for it. That is, we modify the cpu variable, maybe we get
> migrated, but in the end, we just read all the cpu variables and report
> the net sum. Thus the design POV is that we do not care what CPU
> variable we read/write. From an implementation point of view, it just
> happens to be an optimization that we try to read/write to the current
> cpu pointer. But in reality it doesn't matter what CPU variable we
> touch.
> 
> Do not confuse implementation and optimizations with design. The big
> picture design is that we do not care what CPU variable is touched. The
> name should reflect that.

Yep, understood. We might want to consider percpu_*() for the case where
the caller must disable preemption, and any_percpu_*() for the case
where we don't care on which cpu we actually are. These are all touching
per-cpu variables after all. But still, it does not take into account
the "irqsafe" vs "preemptsafe" cases. So maybe irqsafe_any_percpu_*()
and preemptsafe_any_percpu_*() would do it ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com