Messages in this thread | | | Date | Mon, 9 Apr 2007 15:27:17 +0200 | From | Andreas Mohr <> | Subject | Re: Ten percent test |
| |
Hi,
On Mon, Apr 09, 2007 at 02:14:49PM +0200, Rene Herman wrote: > This turned into an interactivity thing, and while interactivity is in > fact better for a large majority of testers, that isn't what Kolivas' > scheduler is about. It's about predictability and leaving the dead-end > road of these endlesss tweaks, which then break previous tweaks, rinse, > repeat. > > It's unfortunate that Kolivas is having health problems currently, but I > certainly do hope that his scheduler finds its way into _a_ -rc1. He > said it was done...
The whole recent discussion/flamefest/... here makes me think that we're still heading towards actually introducing plugsched (most preferrably by making mainline scheduler the builtin default and optionally building a plugsched kernel which then allows selection). There are fundamental behavioural differences between the various CPU scheduler types developed; while some people want a very interactive system with in most(!) cases good latency and exploit-less operation, several others want a scheduler which provides very predictable latency, low overhead and additionally as much interactivity as this strict model can provide for. And then there are people who have very specific SMP requirements which both characteristic scheduler types may have trouble satisfying properly.
And I really don't see much difference whatsoever to the I/O scheduler area: some people want predictable latency, while others want maximum throughput or fastest operation for seek-less flash devices (noop). Hardware varies similarly greatly has well: Some people have huge disk arrays or NAS, others have a single flash disk. Some people have a decaying UP machine, others have huge SMP farms.
IMHO both areas are too varied, thus runtime or compile-time selection is justified for both areas, not simply for I/O schedulers only. I don't think anybody would want to introduce new very similar scheduler types just for the fun of it; development would center around improving the at most 3 or 4 different scheduler implementations (as is the case with I/O schedulers, BTW: there hasn't been an explosion of different variants either!).
I think the whole discussion went on the wrong track when people somehow had the notion of making RSDL (and its later variants) the main scheduler for desktop machines, not just server operation. And this target of course (and rightfully so) prompted people to ask for interactivity similar to what the current scheduler achieves which RSDL cannot fully provide within its strict design, however.
However having mainline remain the only scheduler doesn't seem to be such an attractive option either, e.g. due to its non-predictability, when there exist several alternatives with rather nice behaviour.
Thus I'd still tend towards making things runtime-selectable, scheduler goals are just too varied to ever sufficiently achieve Best Results In Every Area (tm).
Not to mention that making schedulers runtime-selectable would enable uncovering various application timing bugs much faster (e.g. the RPM timing issues that -ck managed to hit).
Oh, and get well very soon, Con, Linux needs you, a lot :)
Andreas Mohr - 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/
| |