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

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]

Date:	Wed, 4 Jun 2014 14:12:37 +0200
From:	Paolo Valente <paolo.valente@...more.it>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Pavel Machek <pavel@....cz>, Tejun Heo <tj@...nel.org>,
	Jens Axboe <axboe@...nel.dk>, Li Zefan <lizefan@...wei.com>,
	Fabio Checconi <fchecconi@...il.com>,
	Arianna Avanzini <avanzini.arianna@...il.com>,
	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org
Subject: Re: BFQ speed tests [was Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler]


Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai <tiwai@...e.de> 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@....cz> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/