Messages in this thread | | | Subject | Re: [PATCH 2/2] Customize sched domain via cpuset | From | Peter Zijlstra <> | Date | Wed, 02 Apr 2008 10:44:31 +0200 |
| |
On Wed, 2008-04-02 at 17:41 +0900, Hidetoshi Seto wrote: > Peter Zijlstra wrote: > > On Tue, 2008-04-01 at 20:27 +0900, Hidetoshi Seto wrote: > >> The implementation is here. > >> > >> - Add 2 new cpuset files: > >> sched_wake_idle_far > >> sched_balance_newidle_far > >> > >> - Modify partition_sched_domains() and build_sched_domains() > >> to take flags parameter passed from cpuset. > >> > >> - Fill newidle_idx for node domains which currently unused but > >> might be required for sched_balance_newidle_far. > > > > Just to be clear; the same effect can be had by poking into: > > > > /proc/sys/kernel/sched_domain/$cpu/$domain/flags > > > > but this interface you now propose gives a more stable interface in that > > you'd have to re-do your setting after every cpuset change (admittedly > > those are rare, but I see how it could be a nuisance). > > And the sysctl entry "sched_domain" is not available unless SCHED_DEBUG. > > So it is common sense that this sysctl is not open to public yet, > and that the expected users are scheduler developers, Ingo and friends.
Ah, right, totally forgot about that :-)
> > Or do you actually add something that wasn't available through the > > initial domain interface? > > At this time I have no idea, but it would be possible if there are > something unreasonable on global system but acceptable on a part. > > In other words, we can invent other sched_* families which has special > effect that "default scheduler" never have.
I was asking about this patch in specific, and the answer seems to be: no, we don't add anything that wasn't available.
And yes, I see the possiblilties to extend this :-)
| |