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 cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
