Re: is RSDL an "unfair" scheduler too?

[Avi Kivity]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/