linux-kernel - Re: BFS vs. mainline scheduler benchmarks and measurements

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: <4AA54AA7.9080709@redhat.com>
Date:	Mon, 07 Sep 2009 21:02:15 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	Ingo Molnar <mingo@...e.hu>, Con Kolivas <kernel@...ivas.org>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements

On 09/07/2009 12:49 PM, Jens Axboe wrote:
>
> I ran a simple test as well, since I was curious to see how it performed
> wrt interactiveness. One of my pet peeves with the current scheduler is
> that I have to nice compile jobs, or my X experience is just awful while
> the compile is running.
>    

I think the problem is that CFS is optimizing for the wrong thing.  It's 
trying to be fair to tasks, but these are meaningless building blocks of 
jobs, which is what the user sees and measures.  Your make -j128 
dominates your interactive task by two orders of magnitude.  If the 
scheduler attempts to bridge this gap using heuristics, it will fail 
badly when it misdetects since it will starve the really important 
100-thread job for a task that was misdetected as interactive.

I think that bash (and the GUI shell) should put any new job (for bash, 
a pipeline; for the GUI, an application launch from the menu) in a 
scheduling group of its own.  This way it will have equal weight in the 
scheduler's eyes with interactive tasks; one will not dominate the 
other.  Of course if the cpu is free the compile job is welcome to use 
all 128 threads.

(similarly, different login sessions should be placed in different jobs 
to avoid a heavily multithreaded screensaver from overwhelming ed).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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