lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched: Fix adverse effects of NFS client on interactive response
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/

\
 
 \ /
  Last update: 2006-01-06 01:43    [W:0.694 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site