linux-kernel - Re: is RSDL an "unfair" scheduler too?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <45FCD449.60303@argo.co.il>
Date:	Sun, 18 Mar 2007 07:55:21 +0200
From:	Avi Kivity <avi@...o.co.il>
To:	Willy Tarreau <w@....eu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	Ingo Molnar <mingo@...e.hu>, Con Kolivas <kernel@...ivas.org>,
	ck@....kolivas.org, Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	Al Boldi <a1426z@...ab.com>, Mike Galbraith <efault@....de>,
	linux-kernel@...r.kernel.org, Nicholas Miell <nmiell@...cast.net>,
	Andrew Morton <akpm@...ux-foundation.org>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/