Messages in this thread | | | Date | Wed, 27 Jul 2011 19:33:14 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: per-cpu operation madness vs validation |
| |
On Wed, 27 Jul 2011, Christoph Lameter wrote: > On Wed, 27 Jul 2011, Peter Zijlstra wrote: > > All this is simply about de-obfuscating all per-cpu assumptions. This is > > about verification and traceability/debuggability. > > Ok verification and traceability are good but they should not > be in the way of making core functionality high performance and low > latency. > > The key issue is that the -rt kernel has always had grave issues with > performance when it comes to per cpu data access. Solving that by forcing > the kernel to go slow it not the right approach.
Nobody want's the kernel to go slow. All we want and we consider that also a benefit for mainline is: proper annotation of the per cpu data access, like we have for RCU and for locking.
Right now everything else than the "atomic" this_cpu stuff needs protection of some sort, but it's nowhere documented and we have no way to prove the correctness.
That has absolutely nothing to do with -rt. We already had cases in mainline where per cpu data structures were accessed without or with wrong protections because the logic changed over time or people made the wrong assumptions.
For -rt this lack of documentation and the lack of verification, debugability and traceability is a major PITA, but that's true for non-rt as well, just the PITA is gradually smaller and the bugs which are there today are just extremly hard to trigger.
And Peters idea of per_cpu_lock*() annotations will boil down to the exact same thing which is there today when you compile the kernel w/o lockdep enabled for per_cpu data correctness. We don't want to change anything or impose any slowness, we just want a proper way to document and verify that maze. That's really not too much of a request.
Thanks,
tglx
| |