Messages in this thread | | | Date | Thu, 29 Aug 2013 14:30:53 -0400 | From | Steven Rostedt <> | Subject | Re: [gcv v3 06/35] scheduler: Replace __get_cpu_var uses |
| |
On Thu, 29 Aug 2013 18:15:43 +0000 Christoph Lameter <cl@linux.com> 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
| |