Messages in this thread | | | Date | Tue, 20 Sep 2011 14:34:56 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write() |
| |
* 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
| |