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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Jun 2014 13:59:35 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Paolo Valente <paolo.valente@...more.it>
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]

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