lkml.org 
[lkml]   [2012]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for linux kernel 3.3.0
On 03/28/2012 07:20 AM, Heinz Diehl wrote:
> On 25.03.2012, Valdis.Kletnieks@vt.edu wrote:
>
>> I'va always wondered what people are using to measure interactivity. Do we have
>> some hard numbers from scheduler traces, or is it a "feels faster"?
>
> I guess it's a "feels faster", because it's the only thing that
> counts.

I think it's inherently difficult to find an objective measure for the
"feeled" smoothness and interactivity of a desktop machine under load.
The measuring process probably needs to reside outside the system under
test and interpret the HDMI output. And control the mouse input.

On a side note, I maintain a little http server and found during testing
that different servers respond differently to different schedulers.
(Note this is about throughput, not interactivity, since this is about
servers and throughput is so easy to measure.) The following is an
unedited quote from the README:


"As an example look at the
following result reading 1000000 static files at concurrency level 100:

Kernel Server Keep- Requests Rate Max.
Version Alive per sec. [ms]
----------------------------------------------------------------------
3.1.4 Apache/2.2.21 yes 25427 33388 265
3.1.4 lighttpd/1.4.29 yes 54741 68892 6
3.1.4 MrHTTPD/2.2.0 yes 88898 100888 5
3.1.4-ck2 Apache/2.2.21 yes 43760 57462 17
3.1.4-ck2 lighttpd/1.4.29 yes 49227 61652 6
3.1.4-ck2 MrHTTPD/2.2.0 yes 163158 185150 2

The throughput offered by MrHTTPD is three to four times higher than
Apache and Lighttpd. Result sets at higher concurrency continue this
trend, and at insane concurrency levels like 10000 or 20000 MrHTTPD is
the only responsive server remaining.

The other stunning fact proven by these figures is the significant
impact of the BFS CPU scheduler and other optimizations inherent in the
CK patch, leading to almost twice the throughput compared to the
vanilla kernel (which was btw configured to use the CFQ scheduler).
This is even more surprising as the design goal of the CK patch is
desktop interactivity rather than server throughput.

It is also noticable that a fully threaded design like MrHTTPD benefits
particularly well from the CK patch, whereas the event-driven design of
Lighttpd often seems to perform slightly better under the vanilla
kernel."


\
 
 \ /
  Last update: 2012-03-28 21:41    [W:0.034 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site