Re: BFQ speed tests [was Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler]
From: Paolo Valente
Date: Wed Jun 04 2014 - 08:13:12 EST
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai <tiwai@xxxxxxx> ha scritto:
> At Wed, 4 Jun 2014 12:24:30 +0200,
> Paolo Valente wrote:
>>
>>
>> Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek <pavel@xxxxxx> ha scritto:
>>
>>> Hi!
>>>
>>>> Should this attempt be useless as well, I will, if you do not mind, try by asking you more details about your system and reproducing your configuration as much as I can.
>>>>
>>>
>>> Try making BFQ the default scheduler. That seems to break it for me,
>>> when selected at runtime, it looks stable.
>>>
>>> Anyway, here are some speed tests. Background load:
>>>
>>> root@duo:/data/tmp# echo cfq > /sys/block/sda/queue/scheduler
>>> root@duo:/data/tmp# echo 3 > /proc/sys/vm/drop_caches
>>> root@duo:/data/tmp# cat /dev/zero > delme; cat /dev/zero > delme;cat
>>> /dev/zero > delme;cat /dev/zero > delme;cat /dev/zero > delme;cat
>>> /dev/zero > delme
>>>
>>> (Machine was running out of disk space.)
>>>
>>> (I alternate between cfq and bfq).
>>>
>>> Benchmark. I chose git describe because it is part of kernel build
>>> sometimes .. and I actually wait for that.
>>>
>>> pavel@duo:/data/l/linux-good$ time git describe
>>> warning: refname 'HEAD' is ambiguous.
>>> v3.15-rc8-144-g405dedd
>>>
>>> Unfortunately, results are not too good for BFQ. (Can you replicate
>>> the results?)
>>>
>>> # BFQ
>>> 10.24user 1.62system 467.02 (7m47.028s) elapsed 2.54%CPU
>>> # CFQ
>>> 8.55user 1.26system 69.57 (1m9.577s) elapsed 14.11%CPU
>>> # BFQ
>>> 11.70user 3.18system 1491.59 (24m51.599s) elapsed 0.99%CPU
>>> # CFQ, no background load
>>> 8.51user 0.75system 30.99 (0m30.994s) elapsed 29.91%CPU
>>> # CFQ
>>> 8.70user 1.36system 74.72 (1m14.720s) elapsed 13.48%CPU
>>>
>>
>> Definitely bad, we are about to repeat the test …
>
> 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.
>
> Rotational disk:
> CFQ:
> 2.32user 3.48system 1:46.97elapsed 5%CPU
> 2.33user 3.41system 1:48.30elapsed 5%CPU
> 2.30user 3.54system 1:48.01elapsed 5%CPU
>
> BFQ:
> 2.41user 3.22system 2:51.96elapsed 3%CPU
> 2.40user 3.19system 2:50.35elapsed 3%CPU
> 2.43user 3.11system 2:46.49elapsed 3%CPU
>
> SSD:
> CFQ:
> 2.37user 3.18system 0:04.70elapsed 118%CPU
> 2.28user 3.26system 0:04.69elapsed 118%CPU
> 2.21user 3.33system 0:04.69elapsed 118%CPU
>
> BFQ:
> 2.35user 2.82system 1:07.85elapsed 7%CPU
> 2.32user 2.90system 0:57.57elapsed 9%CPU
> 2.39user 2.90system 0:55.03elapsed 9%CPU
>
> It's without background task.
>
> BFQ seems behaving bad when reading many small files.
We ran this type of tests (plus checkout, merge and compilation) a long ago, and the performance was about the same as or better than with CFQ. Unfortunately, we have not repeated also these tests anymore since then.
We are already trying to understand what is going wrong.
Thanks,
Paolo
> When I ran "git grep foo HEAD", i.e. performing to the packaged
> repository, the results of both BFQ and CFQ become almost same, as
> expected:
>
> SSD:
> CFQ:
> 7.25user 0.47system 0:09.79elapsed 78%CPU
> 7.26user 0.43system 0:09.75elapsed 78%CPU
> 7.26user 0.43system 0:09.76elapsed 78%CPU
>
> BFQ:
> 7.24user 0.45system 0:09.93elapsed 77%CPU
> 7.31user 0.42system 0:09.90elapsed 78%CPU
> 7.28user 0.42system 0:09.86elapsed 78%CPU
>
>
> thanks,
>
> Takashi
--
Paolo Valente
Algogroup
Dipartimento di Fisica, Informatica e Matematica
Via Campi, 213/B
41125 Modena - Italy
homepage: http://algogroup.unimore.it/people/paolo/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/