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: Windows password security audit tool. GUI, reports in PDF.

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

Message-id: <200703052236.40949.gene.heskett@gmail.com>
Date:	Mon, 05 Mar 2007 22:36:40 -0500
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ed Tomlinson <edt@....ca>,
	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

On Monday 05 March 2007, 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.
>
>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...
>
>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

Thanks Linus, now I feel we're getting somewhere.

Cheers, Gene
-- 
Many hands make light work.
		-- John Heywood
-
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/