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:  <loom.20090908T135340-799@post.gmane.org>
Date:	Tue, 8 Sep 2009 12:00:08 +0000 (UTC)
From:	el_es <el.es.cr@...il.com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: BFS vs. mainline scheduler benchmarks and measurements

Ingo Molnar <mingo <at> elte.hu> writes:

> For example 'Compile' latencies:
> 
> --- Benchmarking simulated cpu of Audio in the presence of simulated Load
>                   Latency +/- SD (ms)  Max Latency   % Desired CPU  %
Deadlines Met
>  v2.6.30: Compile   0.003 +/- 0.00426    0.014             100            100
>      BFS: Compile   0.007 +/- 0.00751    0.019             100            100
> 
> but ... with a near 100% standard deviation that's pretty hard to 
> judge. The Max Latency went from 14 usecs under v2.6.30 to 19 usecs 
> on BFS.
> 
[...]
> 	Ingo
> 

This just struck me : maybe what desktop users *feel* is exactly that : current
approach is too fine-grained, trying to achieve the minimum latency with *most*
reproductible result (less stddev) at all cost ? And BFS just doesn't care? 
I know this sounds like heresy.

[ the space below is to satisfy the brain-dead GMane posting engine].

Lukasz

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