Linux 5.0 I/O Scheduler Benchmarks On Laptop & Desktop Hardware

[Buntolo]

Thanks for the points!

Unfortunately, Jens (the block-layer maintainer) wants new patches by the -rc6 or -rc7 of the previous kernel version ... Here's, e.g., the outcome of a late submission of mine:
https://lkml.org/lkml/2018/8/16/624

I'd say it's for stability reasons. Isn't 5.2 basically 4.24?

[paolo]

I'm giving you 100 internet points. Why only for 5.2 and not 5.1? Is 5.1 already in feature freeze? I can't find any info.

Thanks for the points!

Unfortunately, Jens (the block-layer maintainer) wants new patches by the -rc6 or -rc7 of the previous kernel version ... Here's, e.g., the outcome of a late submission of mine:

https://lkml.org/lkml/2018/8/16/624

[Buntolo]

Ok, I found the cause of this failure on my hw, and I fixed it. The commit is already publicly available for my dev version of bfq, here:

https://github.com/Algodev-github/bfq-mq/

I'll submit this fix/improvement soon for mainline. It'll probably be available only from 5.2 on.

Next Phoronix tests will tell us whether I fully solved the problem, or there is still some other failures triggered by Michael's hardware.

I'm giving you 100 internet points. Why only for 5.2 and not 5.1? Is 5.1 already in feature freeze? I can't find any info.

[paolo]

Gosh, these unbelievably high start-up times with BFQ, when there are writes in the background, mean only one thing: something broke for BFQ in 5.0. I have just reproduced this failure, and, as usual, I'll fix it with a little of luck. The problem is that you guys will see my fix probably only from 5.2 on ... I'm sorry about that.

Ok, I found the cause of this failure on my hw, and I fixed it. The commit is already publicly available for my dev version of bfq, here:

https://github.com/Algodev-github/bfq-mq/

I'll submit this fix/improvement soon for mainline. It'll probably be available only from 5.2 on.

Next Phoronix tests will tell us whether I fully solved the problem, or there is still some other failures triggered by Michael's hardware.

[Melcar]

I used to toy around with scheduler with my old crappy laptop, now I've a powerful quadcore + SSD so I've stopped playing with optimisation. Which scheduler is the best for scenarios?
1- laptop SSD only for everything
Low everyday use, wifi, simple web surfing, using terminals, pure text editor, rare gaming

2- desktop SSD for OS + HDD for data + HDD for games
Gaming, Netflix/Amazon Prime Video, YouTube, web surfing.

I don't think I do anything heavy, like video/photo editing.

On my desktop, also a SATA SSD + HDD combo, I use "none" for the SSD and "mq-deadline" for my HDDs. Works well enough and system remains responsive even with heavy i/o load (something I could not say with Ubuntu's default cfq). Problem is with USB HDDs. Sometimes I get lags and hangs when I try to browse folders with large amounts of images for example, or even worse, after doing large transfers to my USB drives the desktop sort of locks up the drive and does not let me remove it gracefully. I tried other mq schedulers, but they all have similar issues with USB HDDs.

[paolo]

Gosh, these unbelievably high start-up times with BFQ, when there are writes in the background, mean only one thing: something broke for BFQ in 5.0. I have just reproduced this failure, and, as usual, I'll fix it with a little of luck. The problem is that you guys will see my fix probably only from 5.2 on ... I'm sorry about that.

[Buntolo]

I used to toy around with scheduler with my old crappy laptop, now I've a powerful quadcore + SSD so I've stopped playing with optimisation. Which scheduler is the best for scenarios?
1- laptop SSD only for everything
Low everyday use, wifi, simple web surfing, using terminals, pure text editor, rare gaming

2- desktop SSD for OS + HDD for data + HDD for games
Gaming, Netflix/Amazon Prime Video, YouTube, web surfing.

I don't think I do anything heavy, like video/photo editing.

[coder]

53 seconds to start xterm? That surely has to be a bug!

Note that there's background I/O. Read the fine print. On a related note, the disk cache is probably devoid of most the needed files & filesystem metadata.

Also, when I run strace xterm, I get 97 open() calls and 298 read()s. Most of those will be for ordinary files. When reading from a filesystem, an open() would typically translate into several I/O reads, as the kernel walks the filesystem datastructures, reads metadata, etc. read()s could translate in to more or less than 1:1, depending on their size, their relative locations, and whether the kernel is prefetching.

So, I'd agree that it's pretty appalling, but not inconceivable.

[coder]

What's that about Flexible I/O Tester combining Linux AIO with "Buffered: Yes"? I thought Linux AIO only worked with O_DIRECT, or was that changed?

Or maybe it's referring to user-space buffering in the app, itself?

[CarlGWatts]

Isn't the performance of the OS I/O schedulers heavily influenced by the particular firmware algorithms used in the SSD controller? And doesn't that make these benchmark measurements of the performance of the OS I/O schedulers only relevant for the particular SSDs used in your testing?

If so, wouldn't it be better to perform these benchmarks on a bare eMMC chip or an SD card where there is no sophisticated firmware software between the OS I/O scheduler and the flash memory?