lkml.org 
[lkml]   [2007]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2007-03-18 06:57    [W:0.206 / U:1.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site