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:  <45FEFD49.2080507@tmr.com>
Date:	Mon, 19 Mar 2007 17:14:49 -0400
From:	Bill Davidsen <davidsen@....com>
To:	linux-kernel@...r.kernel.org
Cc:	ck@....kolivas.org
Subject:  Re: is RSDL an "unfair" scheduler too?

Bill Huey (hui) wrote:
> On Sun, Mar 18, 2007 at 06:24:40AM +0100, Willy Tarreau wrote:
>>> Dunno. I guess a lot of people would like to then manage the classes, 
>>> which would be painful as hell. 
>> Sure ! I wouldn't like people to point the finger on Linux saying "hey
>> look, they can't write a good scheduler so you have to adjust the knobs
>> yourself!". I keep in mind that Solaris' scheduler is very good, both
>> fair and interactive. FreeBSD was good (I haven't tested for a long time).
>> We should manage to get something good for most usages, and optimize
>> later for specific uses.
> 
> Like I've said in a previous email, SGI schedulers have an interactive
> term in addition to the normal "nice" values. If RSDL ends up being too
> rigid for desktop use, then this might be a good idea to explore in
> addition to priority manipulation.
> 
> However, it hasn't been completely proven that RSDL can't handle desktop
> loads and that needs to be completely explored first. It certain seems
> like, from the .jpgs that were posted earlier in the thread regarding mysql
> performance, that RSDL seems to have improved performance for those set
> ups so it's not universally the case that it sucks for server loads. The
> cause of this performance difference has yet to be pinpointed.

I would say that RSDL is probably a bit better than default for server 
use, although if the server starves for CPU interactive processing at 
the console becomes leisurely indeed. The only thing I would like to 
address is the order of magnitude blips in latency of nice processes, 
which may be solved by playing with time slices. Con hasn't really 
commented on that (or I haven't read down to it).

> 
> Also, bandwidth scheduler like this are a new critical development for
> things like the -rt patch. It would benefit greatly if the RSDL basic
> mechanisms (RR and deadlines) were to somehow slip into that patch and
> be used for a more strict -rt based scheduling class. It would be the basis
> for first-class control over process resource usage and would be a first
> in Linux or any mainstream kernel.

I don't think that RSDL and -rt should be merged, but that's for Ingo 
and Con to discuss. I would love to see RSDL in mainline as soon as it 
is practical, marked as EXPERIMENTAL.
> 
> This would be a powerful addition to Linux as a whole and RSDL should
> not be dismissed without these considerations. If it can somehow be
> integrated into the kernel with interactivity concerns addressed, then
> it would be an all out win for the kernel in both these areas.
> 
I don't think there are a lot of places where it underperforms the 
default scheduler, and it avoids a lot of jackpot cases where an 
overloaded system really bogs down. I would like to see more varied 
testing before any changes are made, unless a simple change would 
improve consistency of latency.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

-
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/