On Fri, 2008-05-30 at 11:06 -0700, Christoph Lameter wrote: > On Fri, 30 May 2008, Peter Zijlstra wrote: > > > For one the fixed size alloction limit as pointed out by Andrew. > > Ok. > > > What this does is make a strong connection between data and concurrency > > control. Your proposed scheme weakens the data<->concurrency relation > > instead of making it stronger. > > > > One sign of that is that you replace things like get_cpu with explicit > > preempt_disable(). > > That is a side effect of trying to make transformation of source code > easily visible. Its not necessary if some changes are made to the code. > > > We're trying to get rid of as many explicit preempt_disable()s as > > possible - in the light of -rt, preempt_disable() is as bad as the BKL > > in that its opaque - unrelated to a specific data set. > > The cpu ops patches get rid of lots of preempt enable /disable and > get_cpu/put_cpu() because the per cpu address determination no longer > needs to be protected. See some of the other patches. Some code may need > to be a bit rewritten to take advantage. The SLUB fastpath f.e. (and > likely the page allocator too) can be done exclusively with CPU_OPS > thereby avoiding locks and preemption issues. Sure, that's good stuff, and I'm not objecting to that. But for example the perpcu_counter, workqueue, (nfs), module handling, slub and page allocator can use the scheme I proposed. Please consider adding this get/put interface. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
