Re: [ANNOUNCE] BFS CPU scheduler version 0.420 AKA "Smoking" for linux kernel 3.3.0

[Martin Rogge <marogge@onlinehome.de>]

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."