On Thu, 29 Aug 2013 18:15:43 +0000 Christoph Lameter <cl@xxxxxxxxx> wrote: > On Thu, 29 Aug 2013, Steven Rostedt wrote: > > Its not really an atomic operation in the classic sense. It doesn't need to be atomic, it could mean it is used within atomic locations. Basically, "can't be interrupted here". I just said "something like", it didn't even need to be that. > > this_cpu_no_preempt_check_read ? I would make it much shorter. You could use "raw_this_cpu_read()", which usually means "no checks here". Or, "this_cpu_read_nopreempt()". > > The problem that I have is also that a kernel with preemption is not > something that see anywhere these days. Looks more like an academic > exercise? Does this really matter? All the distro I see use Um, my paycheck depends on PREEMPT_RT working. And there's a lot of interest in real PREEMPT by audio folks. It's no more an academic exercise than people wanting really low kernel latency. > PREEMPT_VOLUNTARY. Performance degradation is significant if massive > amounts of checks and preempt disable/enable points are added to the > kernel. They are usually disabled for production systems. But we run a bunch of tests with the debug checks enabled, which catch bugs before we ship a kernel for a production system. > > Do we agree that it is necessary and useful to add another variant of > this_cpu ops for this? The concern of having too many variants is no > longer there? Adding another variant is not that difficult just code > intensive. How many places use the this_cpu_*() without preemption disabled? I wouldn't think there's many. I never complained about another variant, so you need to ask those that have. The tough question for me is what that variant name should be ;-) -- Steve -- 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
