Re: [patch 4/5] sched: RCU sched domains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* Nick Piggin <[email protected]> wrote:


4/5


One of the problems with the multilevel balance-on-fork/exec is that it needs to jump through hoops to satisfy sched-domain's locking semantics (that is, you may traverse your own domain when not preemptable, and you may traverse others' domains when holding their runqueue lock).

balance-on-exec had to potentially migrate between more than one CPU before finding a final CPU to migrate to, and balance-on-fork needed to potentially take multiple runqueue locks.

So bite the bullet and make sched-domains go completely RCU. This actually simplifies the code quite a bit.

Signed-off-by: Nick Piggin <[email protected]>


i like it conceptually, so:

Acked-by: Ingo Molnar <[email protected]>


Oh good, thanks.

from now on, all domain-tree readonly uses have to be rcu_read_lock()-ed (or otherwise have to be in a non-preemptible section). But there's a bug in show_shedstats() which does a for_each_domain() from within a preemptible section. (It was a bug with the current hotplug logic too i think.)


Ah, thanks. That looks like a bug in the code with the locking
we have now too...

At a minimum i think we need the fix+comment below.


Well if we say "this is actually RCU", then yes. And we should
probably change the preempt_{dis|en}ables in other places to
rcu_read_lock.

OTOH, if we say we just want all running threads to process through
a preemption stage, then this would just be a preempt_disable/enable
pair.

In practice that makes no difference yet, but it looks like you and
Paul are working to distinguish these two cases in the RCU code, to
accomodate your low latency RCU stuff?

I'd prefer the latter (ie. just disable preempt, and use
synchronize_sched), but I'm not too sure of what is going on with
your the low latency RCU work...?

	Ingo

Signed-off-by: Ingo Molnar <[email protected]>


Thanks for catching that. I may just push it through first as a fix
to the current 2.6 schedstats code (using preempt_disable), and
afterwards we can change it to rcu_read_lock if that is required.

--
SUSE Labs, Novell Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux