linux-kernel - Re: [test] sched: SD-latest versus Mike's latest

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]

Message-Id: <200704060208.47327.kernel@kolivas.org>
Date:	Fri, 6 Apr 2007 02:08:47 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Mike Galbraith <efault@....de>,
	linux list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: [test] sched: SD-latest versus Mike's latest

On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> wrote:
> > On Tue, 2007-04-03 at 08:01 +0200, Ingo Molnar wrote:
> > > looks interesting - could you send the patch?
> >
> > Ok, this is looking/feeling pretty good in testing.  Comments on
> > fugliness etc much appreciated.
> >
> > Below the numbers is a snapshot of my experimental tree.  It's a
> > mixture of my old throttling/anti-starvation tree and the task

Throttling to try to get to SD fairness? The mainline state machine becomes 
more complex than ever and fluctuates from interactive to fair by an as-yet 
unchosen magic number timeframe which ebbs and flows.

> > promotion patch, with the addition of a scheduling class for
> > interactive tasks to dish out some of that targeted unfairness I
> > mentioned.

Nice -10 on mainline ruins the latency of nice 0 tasks unlike SD. New 
scheduling class just for X? Sounds like a very complicated 
userspace-changing way to just do the equivalent of "nice -n -10" obfuscated. 

> here's some test results, comparing SD-latest to Mike's-latest:
>
> re-testing the weak points of the vanilla scheduler + Mike's:
>
>  - thud.c:    this workload has almost unnoticeable effect
>  - fiftyp.c:  noticeable, but alot better than previously!

Load of 1.5 makes mainline a doorstop without throttling.

> re-testing the weak points of SD:
>
>  - hackbench: still unusable under such type of high load - no improvement.

Load of 160. Is proportional slowdown bad?

>  - make -j:   still less interactive than Mike's - no improvement.

Depends on how big your job number vs cpu is. The better the throttling gets 
with mainline the better SD gets in this comparison. At equal fairness 
mainline does not have the low latency interactivity SD has.

Nice -10 X with SD is a far better solution than an ever increasing complexity 
state machine and a userspace-changing scheduling policy just for X. Half 
decent graphics cards get good interactivity with SD even without renicing.

> 	Ingo

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