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