Messages in this thread | | | Date | Sun, 18 Mar 2007 07:55:21 +0200 | From | Avi Kivity <> | Subject | Re: is RSDL an "unfair" scheduler too? |
| |
Willy Tarreau wrote: > On Sat, Mar 17, 2007 at 06:32:29PM -0700, Linus Torvalds wrote: > >> On Sat, 17 Mar 2007, William Lee Irwin III wrote: >> >>> One issue this raises is prioritizing users on a system, threads within >>> processes, jobs within users, etc. >>> >> Doing some "classing" even by just euid might be a good idea. It would >> actually catch X automatically most of the time, because the euid of the X >> server is likely to be root, so even for the "trivial" desktop example, it >> would kind of automatically mean that X would get about 50% of CPU time >> even if you have a hundred user clients, just because that's "fair" by >> euid. >> > > Warning: all these ideas seem interesting for desktop, but are definitely > not for servers. I found RSDL to be excellent on servers, compared to > mainline in which some services are starving under load. I can understand > that on the desktop people want some unfairness, and I like the pgrp idea > for instance. But this one will certainly fail on servers, or make the > admins get grey hair very soon. >
I didn't suggest adding any unfairness! I suggested being fair by user/job/process instead of being fair by thread (which is actually unfair as it favors multi threaded processes over single threaded processes).
> Maybe we're all discussing the problem because we have reached the point > where we need two types of schedulers : one for the desktop and one for > the servers. After all, this is already what is proposed with preempt, > it would make sense provided they share the same core and avoid ifdefs > or unused structure members. Maybe adding OPTIONAL unfairness to RSDL > would help some scenarios, but in any case it is important to retain > the default fairness it provides. >
I hope not. I think that reducing the timeslice base, combined with renicing X all the way to hell should suffice.
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
- 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/
| |