On Sun, Apr 29, 2007 at 03:37:47PM +0200, Thomas Gleixner wrote:
> On Sun, 2007-04-29 at 05:55 -0700, William Lee Irwin III wrote:
> > You'll also hit the same holes should you attempt to write such a
> > modularity patch for mainline as opposed to porting current mainline to
> > the driver API as-given. It takes a bit more work to get something that
> > actually works for all this, and it borders on disingenuity to
> > suggest that the scheduler class/driver API as it now stands is
> > capable of any such thing as porting current mainline, nicksched, or SD
> > to it without significant code impact to the core scheduler code.
>
> I never said, that the current implementation of CFS fits the criteria
> of modularity, but it is a step in that direction. I'm well aware that
> there is a bunch of things missing and it has hard coded leftovers,
> which are related to the current two hard coded policy classes.
[ I've tuned out of most of the scheduler discussion lately, sorry ;) ]
People seem to be confusing scheduler policy with a modular framework.
First of all, I don't know that any of the schedulers can "just go in"
and replace the mainline one, because they are still under development
and have not been sufficiently tested and contrasted IMO.
Secondly, if we want to have a modular framework, it should:
- be a seperate patchset to any new scheduler policy
- obviously retain the existing policy for testing / comparison purposes
- be able to be compiled out. I don't know whether it's CFS policy or
the framework (maybe both), but CFS is quite a bit slower at context
switching when I last measured with lmbench (several releases ago).
I still would rather not have a modular framework unless we decide
that is the only wake to make upstream progress. But if we did have
the modular framework, we still need to decide on the process of
avoiding profileration, selecting a default scheduler, and a plan for
future phasing out of non-default GP schedulers once a new one gets
selected.
On Tue, May 01, 2007 at 09:55:15AM +0200, Nick Piggin wrote:
> People seem to be confusing scheduler policy with a modular framework.
> First of all, I don't know that any of the schedulers can "just go in"
> and replace the mainline one, because they are still under development
> and have not been sufficiently tested and contrasted IMO.
I've already made noise about separate modular framework patches, so
recast whatever confusion seems apparent to you in those terms.
On Tue, May 01, 2007 at 09:55:15AM +0200, Nick Piggin wrote:
> Secondly, if we want to have a modular framework, it should:
> - be a seperate patchset to any new scheduler policy
> - obviously retain the existing policy for testing / comparison purposes
> - be able to be compiled out. I don't know whether it's CFS policy or
> the framework (maybe both), but CFS is quite a bit slower at context
> switching when I last measured with lmbench (several releases ago).
Compiling such things out is interesting at best, as they typically
require significant code restructuring. You can make the indirect calls
conditional by calling some particular driver directly inside wrapper
macros for the indirect calls via case analysis on ->policy, I suppose.
There are issues with using cfs' notion of a modular framework to
verify performance non-regression, in particular the fact it's
incapable of representing mainline. There is also the problem of doing
very little in the way of hiding data, so that in the event of using it
to compare different implementations of the same policy, e.g. competing
SCHED_OTHER implementations, each is stuck maintaining the others'
state variables, save for the case where one or both happens to have
all its state variable updates fit entirely inside the driver operations,
in which case they still take the hit for bloating the task_struct, and
worse yet, some asymmetry in terms of which is exempt from maintaining
the others' state variables occurs which furthermore penalizes the
competitor maintaining the least state or doing the least state updates.
Such a state of affairs must not be allowed to stand.
On Tue, May 01, 2007 at 09:55:15AM +0200, Nick Piggin wrote:
> I still would rather not have a modular framework unless we decide
> that is the only wake to make upstream progress. But if we did have
> the modular framework, we still need to decide on the process of
> avoiding profileration, selecting a default scheduler, and a plan for
> future phasing out of non-default GP schedulers once a new one gets
> selected.
It certainly cuts down on the eye bleed but I suppose that takes a
back seat to performance considerations.
-- wli