Re: [PATCH] sched: Fix adverse effects of NFS client on interactive response

[Peter Williams <pwil3058@bigpond.net.au>]

Con Kolivas wrote:
> On Fri, 6 Jan 2006 11:02 am, Peter Williams wrote:
>
> > Con Kolivas wrote:
> >
> > > On Fri, 6 Jan 2006 10:13 am, Peter Williams wrote:
> > >
> > > > If the plugsched patches were included in -mm we could get wider testing
> > > > of alternative scheduling mechanisms.  But I think it will take a lot of
> > > > testing of the new schedulers to allay fears that they may introduce new
> > > > problems of their own.
> > >
> > > When I first generated plugsched and posted it to lkml for inclusion in
> > > -mm it was blocked as having no chance of being included by both Ingo and
> > > Linus and I doubt they've changed their position since then. As you're
> > > well aware this is why I gave up working on it and let you maintain it
> > > since then. Obviously I thought it was a useful feature or I wouldn't
> > > have worked on it.
> >
> > I've put a lot of effort into reducing code duplication and reducing the
> > size of the interface and making it completely orthogonal to load
> > balancing so I'm hopeful (perhaps mistakenly) that this makes it more
> > acceptable (at least in -mm).
>
>
> The objection was to dilution of developer effort towards one cpu scheduler to 
> rule them all.

I think that I've partially addressed that objection by narrowing the 
focus of the alternative schedulers so that the dilution of effort is 
reduced.  The dichotomy between the dual array schedulers (ingosched and 
nicksched) and the single array schedulers (staircase and the SPA 
schedulers) is the main stumbling block to narrowing the focus further.

> Linus' objection was against specialisation - he preferred one 
> cpu scheduler that could do everything rather than unique cpu schedulers for 
> NUMA, SMP, UP, embedded...

kernbench results show that the penalties for an all purpose scheduler 
aren't very big so it's probably not a bad philosophy.  In spite of this 
I think specialization is worth pursuing if it can be achieved with very 
small configurable differences to the mechanism.  If the configuration 
change can be done at boot time or on a running system then it's even 
better e.g. your "compute" switch in staircase.

> Each approach has its own arguments and there 
> isn't much point bringing them up again. We shall use Linux as the 
> "steamroller to crack a nut" no matter what that nut is.

Even if plugsched has no hope of getting into the mainline kernel, I see 
it as a useful tool for the practical evaluation of the various 
approaches.  If it could go into -mm for a while this evaluation could 
be more widespread.

In it's current state it should not interfere with other scheduling 
related development such as the load balancing changes, cpusets etc.

> > My testing shows that there's no observable difference in performance
> > between a stock kernel and plugsched with ingosched selected at the
> > total system level (although micro benchmarking may show slight
> > increases in individual operations).
>
>
> I could find no difference either, but IA64 which does not cope with 
> indirection well would probably suffer a demonstrable performance hit I have 
> been told.

I wasn't aware of that.

> I do not have access to such hardware.

Nor do I.

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/