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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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                                   [email protected]

"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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux