Fwd: About BFQ interaction with git filter-branch

Fwd: About BFQ interaction with git filter-branch

[Pacho Ramos]

(Resending as text plain as it seems HTML is tagged as SPAM, sorry for
the noise)

---------- Forwarded message ---------
De: Pacho Ramos <pachoramos@gmail.com>
Date: lun., 8 abr. 2019 a las 14:38
Subject: About BFQ interaction with git filter-branch
To: Paolo VALENTE <paolo.valente@unimore.it>
Cc: <bfq-iosched@googlegroups.com>, <linux-block@vger.kernel.org>


I wanted to simply give you thanks to you and BFQ team. It's the only
scheduler allowing me to be able to work with my computer even running
 git filter-branch --force --tree-filter... at the same time.

And that huge difference is with a SSD disk, even if some people in
internet suggest that noop or mq-deadline would perform better for
them. Maybe for throughput it could perform a bit worse... I don't
know, but for being able to work with the system and not simply need
to move to other computer to work, BFQ clearly wins.

Thanks for your work, hopefully it will be chosen by default for not
needing to play with udev rules or echo ... >

Maybe you could try to add this test with git filter-branch to your
benchmarks. In my case I have tested with: none, mq-deadline
(kernel-5.0.7) , deadline, cfq, noop (kernel 4.19.32) on a Gentoo
Linux system running their gentoo-sources kernel (mostly vanilla
kernel) while trying to work with a Gnome 3.24 desktop, Chrome,
terminal...

The harddisk is SanDisk X400 2.5 7MM 512GB (X4152012) and cpu is
Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz

Best regards!

Re: About BFQ interaction with git filter-branch

[Paolo Valente]

> Il giorno 8 apr 2019, alle ore 14:40, Pacho Ramos <pachoramos@gmail.com> ha scritto:
> 
> (Resending as text plain as it seems HTML is tagged as SPAM, sorry for
> the noise)
> 
> ---------- Forwarded message ---------
> De: Pacho Ramos <pachoramos@gmail.com>
> Date: lun., 8 abr. 2019 a las 14:38
> Subject: About BFQ interaction with git filter-branch
> To: Paolo VALENTE <paolo.valente@unimore.it>
> Cc: <bfq-iosched@googlegroups.com>, <linux-block@vger.kernel.org>
> 
> 
> I wanted to simply give you thanks to you and BFQ team.

You're very welcome.

> It's the only
> scheduler allowing me to be able to work with my computer even running
> git filter-branch --force --tree-filter... at the same time.
> 

Great!  This seems a demanding instance of the personal use cases that
I had in mind while designing BFQ heuristics.

> And that huge difference is with a SSD disk, even if some people in
> internet suggest that noop or mq-deadline would perform better for
> them. Maybe for throughput it could perform a bit worse...

Fortunately no.  Thanks to the last developments [1], even the last
throughput gaps seem to have been filled.  With commodity CPUs, BFQ
reaches the same or higher throughput than the other I/O schedulers,
with SSDs peaking up to ~500 KIOPS.

[1] https://lwn.net/Articles/784267/ (wait for one more week if you
				      are not an LWN subscriber, or
				      subscribe! :) )


> I don't
> know, but for being able to work with the system and not simply need
> to move to other computer to work, BFQ clearly wins.
> 
> Thanks for your work, hopefully it will be chosen by default for not
> needing to play with udev rules or echo ... >
> 

That's hard to say.  So far, all numbers have been in favor of BFQ,
but this didn't convince, e.g., Jens himself.  IIRC, Jen's last
request was:

"I'm mostly just interested in plain fast NVMe device, and a big box
hardware raid setup with a ton of drives."

Now we have plenty of results on NVMe drives, but I still don't know
well how to proceed with raids with a ton of drives.  The problem is
not much that a ton of drives is not a precise number, but that it may
hint at so large configurations that I'm unlikely to own them.  If
Jens, or anybody else able to access such a hardware, can give access
to me too, for some test, I'd be very happy to compare all I/O
schedulers on their systems of interest.

> Maybe you could try to add this test with git filter-branch to your
> benchmarks.

I'll consider adding also this test to my kern-dev set of sets (now it
includes only make, git checkout and git merge).

> In my case I have tested with: none, mq-deadline
> (kernel-5.0.7) , deadline, cfq, noop (kernel 4.19.32) on a Gentoo
> Linux system running their gentoo-sources kernel (mostly vanilla
> kernel) while trying to work with a Gnome 3.24 desktop, Chrome,
> terminal...
> 
> The harddisk is SanDisk X400 2.5 7MM 512GB (X4152012) and cpu is
> Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz
> 

A rather thorough test.  From 5.2, for such a test you should get
even better performance with BFQ, compared to 4.19.

Thanks,
Paolo

> Best regards!