linux-kernel - Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 08 Mar 2007 23:04:07 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ed Tomlinson <edt@....ca>, Gene Heskett <gene.heskett@...il.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lee Revell <rlrevell@...-job.com>,
	Nicolas Mailhot <nicolas.mailhot@...oste.net>
Subject: Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu
   scheduler

Linus Torvalds wrote:
> 
> On Mon, 5 Mar 2007, Ed Tomlinson wrote:
>> The patch _does_ make a difference.  For instance reading mail with freenet working 
>> hard  (threaded java application) and gentoo's emerge triggering compiles to update the 
>> box is much smoother.
>>
>> Think this scheduler needs serious looking at.  
> 
> I agree, partly because it's obviously been getting rave reviews so far, 
> but mainly because it looks like you can think about behaviour a lot 
> better, something that was always very hard with the interactivity 
> boosters with process state history.
> 
> I'm not at all opposed to this, but we do need:
>  - to not do it at this stage in the stable kernel
>  - to let it sit in -mm for at least a short while
>  - and generally more people testing more loads.
> 
Please, could you now rethink plugable scheduler as well? Even if one 
had to be chosen at boot time and couldn't be change thereafter, it 
would still allow a few new thoughts to be included.

> I don't actually worry too much about switching out a CPU scheduler: those 
> things are places where you *can* largely read the source code and get an 
> idea for them (although with the kind of history state that we currently 
> have, it's really really hard). But at the very least they aren't likely 
> to have subtle bugs that show up elsewhere, so...
> 
I confess that the default scheduler works for me most of the time, i/o 
tuning is more productive. I want tot test with kvm load, but 
2.6.21-rc3-git3 doesn't want to run kvm at all, I'm looking to see what 
I broke, since nbd doesn't work, either.

I'm collecting OOPS now, will forward when I have a few more.

> So as long as the generic concerns above are under control, I'll happily 
> try something like this if it can be merged early in a merge window..
> 
> 			Linus


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