linux-kernel - Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

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: <1173697024.8014.19.camel@Homer.simpson.net>
Date:	Mon, 12 Mar 2007 11:57:04 +0100
From:	Mike Galbraith <efault@....de>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	ck list <ck@....kolivas.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> > 
> Now I think you're getting carried away because of your expectations from the 
> previous scheduler and its woefully unfair treatment towards interactive 
> tasks. Look at how you're loading up your poor P4 even with HT. You throw 2 
> cpu hogs only gently niced at it on top of your interactive tasks. If you're 
> happy to nice them +5, why not more? And you know as well as anyone that the 
> 2nd logical core only gives you ~25% more cpu power overall so you're asking 
> too much of it. Let's not even talk about how lovely this will (not) be once 
> SMT nice gets killed off come 2.6.21 and nice does less if "buyer beware" you 
> chose to enable HT in your own words.

The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain intact.
I understand the concepts here Con, and I'm not knocking your scheduler.
I find it to be a step forward on the one hand, but a step backward on
the other.

Tossing in the SMT nice comment was utter bullshit.  All kernels tested
were missing SMT nice.

> > When I looked into keeping interactive tasks responsive, I came to the
> > conclusion that I just couldn't get there from here across the full
> > spectrum of cpu usage without a scheduler hint.  Interactive feel is
> > absolutely dependent upon unfairness in many cases, and targeting that
> > unfairness gets it right where heuristics sometimes can't.
> 
> See above. Your expectations of what you should be able to do are simply 
> skewed. Find what cpu balance you loved in the old one (and I believe it 
> wasn't that much more cpu in favour of X if I recall correctly) and simply 
> change the nice setting on your lame encoder - since you're already setting 
> one anyway.
> 
> We simply cannot continue arguing that we should dish out unfairness in any 
> manner any more. It will always come back and bite us where we don't want it.

Unless you target accurately.

> We are getting good interactive response with a fair scheduler yet you seem 
> intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING.  Was.

	bye,

	-Mike

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