Messages in this thread | | | Date | Wed, 06 Apr 2005 18:09:32 +1000 | From | Nick Piggin <> | Subject | Re: [patch 5/5] sched: consolidate sbe sbf |
| |
Ingo Molnar wrote: > * Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > >>5/5 >> >>Any ideas about what to do with schedstats? >>Do we really need balance on exec and fork as seperate >>statistics? > > >>Consolidate balance-on-exec with balance-on-fork. This is made easy >>by the sched-domains RCU patches. >> >>As well as the general goodness of code reduction, this allows >>the runqueues to be unlocked during balance-on-fork. >> >>schedstats is a problem. Maybe just have balance-on-event instead >>of distinguishing fork and exec? >> >>Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au> > > > looks good. >
One problem I just noticed, sorry. This is doing set_cpus_allowed without holding the runqueue lock and without checking the hard affinity mask either.
We could just do a set_cpus_allowed, or take the lock, set_cpus_allowed, and take the new lock, but that's probably a bit heavy if we can avoid it. In the interests of speed in this fast path, do you think we can do this in sched_fork, before the task has even been put on the tasklist?
That would avoid all locking problems. Passing clone_flags into sched_fork would not be a problem if we want to distinguish fork() and clone(CLONE_VM).
Yes? I'll cut a new patch to do just that.
> Acked-by: Ingo Molnar <mingo@elte.hu> > > while the code is now consolidated, i think we still need the separate > fork/exec stats for schedstat.
This makes it a bit harder then, to get good stats in the sched-domain (which is really what we want). It would basically mean doing if (balance fork) schedstat_inc(sbf_cnt); else if (balance exec) schedstat_inc(sbe_cnt); etc.
That should all get optimised out by the compiler, but still a bit ugly. Any ideas?
-- SUSE Labs, Novell Inc.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |