Thread (107 messages) 107 messages, 8 authors, 2014-07-09

Re: BFQ speed tests [was Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler]

From: Takashi Iwai <hidden>
Date: 2014-06-13 16:21:36
Also in: lkml

At Wed, 11 Jun 2014 22:45:06 +0200,
Paolo Valente wrote:

Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai [off-list ref] ha scritto:
quoted
[…]
I've been using BFQ for a while and noticed also some obvious
regression in some operations, notably git, too.
For example, git grep regresses badly.

I ran "test git grep foo > /dev/null" on linux kernel repos on both
rotational disk and SSD.
[…]

BFQ seems behaving bad when reading many small files.
The fix I described in my last reply to Pavel's speed tests
(https://lkml.org/lkml/2014/6/4/94) apparently solves also this problem.
As I wrote in that reply, the new fixed version of bfq is here:
http://algogroup.unimore.it/people/paolo/disk_sched/debugging-patches/3.16.0-rc0-v7rc5.tgz

These are our results, for your test, with this fixed version of bfq.

time git grep foo > /dev/null

Rotational disk:
 CFQ:
   2.86user 4.87system 0:29.51elapsed 26%CPU
   2.87user 4.87system 0:30.30elapsed 25%CPU
   2.82user 4.90system 0:29.13elapsed 26%CPU

 BFQ:
   2.81user 4.97system 0:25.96elapsed 29%CPU
   2.83user 5.02system 0:24.79elapsed 31%CPU
   2.85user 4.95system 0:24.73elapsed 31%CPU

SSD:
 CFQ:
   2.04user 3.93system 0:03.88elapsed 153%CPU
   2.12user 3.85system 0:03.89elapsed 153%CPU
   2.05user 3.92system 0:03.89elapsed 153%CPU

 BFQ:
   2.10user 3.86system 0:03.89elapsed 153%CPU
   2.05user 3.90system 0:03.88elapsed 153%CPU
   2.01user 3.95system 0:03.89elapsed 153%CPU

time git grep foo HEAD > /dev/null

SSD:
 CFQ:
   5.11user 0.38system 0:06.71elapsed 81%CPU
   5.21user 0.36system 0:06.78elapsed 82%CPU
   5.05user 0.41system 0:06.69elapsed 81%CPU

 BFQ:
   5.17user 0.39system 0:06.77elapsed 82%CPU
   5.13user 0.37system 0:06.73elapsed 81%CPU
   5.17user 0.37system 0:06.78elapsed 81%CPU

Should you be willing to provide further feedback on this and other tests,
we would of course really appreciate it.
Thanks.  The new patchset works well now.  The results with the new
patchset + latest Linus git tree are below.

The only significant difference is the case with "git grep foo" on
SSD.  But I'm not sure whether it's a casual error.  I'll need to get
more samples to flatten the errors.


Takashi

===

* time git grep foo > /dev/null

rotational disk:
  CFQ:
    2.34user 4.04system 2:00.12elapsed 5%CPU
    2.49user 3.80system 1:56.20elapsed 5%CPU
    2.42user 3.68system 1:46.81elapsed 5%CPU

  BFQ:
    2.44user 3.57system 1:49.65elapsed 5%CPU
    2.47user 3.67system 1:55.92elapsed 5%CPU
    2.47user 3.63system 1:50.06elapsed 5%CPU

SSD:
  CFQ:
    1.25user 1.54system 0:04.62elapsed 60%CPU
    1.23user 1.67system 0:04.65elapsed 62%CPU
    1.22user 1.60system 0:04.61elapsed 61%CPU

  BFQ:
    1.29user 1.64system 0:06.91elapsed 42%CPU
    1.30user 1.66system 0:06.66elapsed 44%CPU
    1.27user 1.59system 0:04.73elapsed 60%CPU

* time git grep foo HEAD > /dev/null

rotational disk:
  CFQ:
    5.12user 0.43system 0:19.86elapsed 28%CPU
    5.06user 0.45system 0:19.88elapsed 27%CPU
    5.00user 0.41system 0:20.05elapsed 27%CPU

  BFQ:
    4.82user 0.37system 0:19.56elapsed 26%CPU
    5.00user 0.43system 0:19.53elapsed 27%CPU
    4.92user 0.45system 0:19.69elapsed 27%CPU

SSD:
  CFQ:
    4.49user 0.32system 0:07.26elapsed 66%CPU
    4.50user 0.31system 0:07.25elapsed 66%CPU
    4.40user 0.32system 0:07.16elapsed 65%CPU

  BFQ:
    4.09user 0.26system 0:06.93elapsed 62%CPU
    3.76user 0.23system 0:06.54elapsed 61%CPU
    3.65user 0.22system 0:06.40elapsed 60%CPU
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help