io-scheduler: Use kyber for nvme's and ssd's

[ptr1337]

I have tested kyber for the nvme in various workloads and it does improve the repressives of the desktop under heavy IO scenarios a lot compared to "none".

Throughput appears to be lower for around 3% in my testings (tested with kdiskmark).

Also see following:

pop-os/default-settings#149

Fixes: #34

[John-Gee]

I'm curious what your reasons were for reverting this.

Lately (not sure since when exactly) my system has been crawling under heavy IO and now it makes me wonder if the revert was the cause, but maybe not.

edit: nope that was not it, it happened again after reverting.

[ptr1337]

I'm curious what your reasons were for reverting this.

Lately (not sure since when exactly) my system has been crawling under heavy IO and now it makes me wonder if the revert was the cause, but maybe not.

edit: nope that was not it, it happened again after reverting.

Mainly because we noticed a regression in benchmarks related to that.
Generally the responives should be better with kyber, there you right.

I saw also some regression on heavy IO, it seems like there is some regression in the 6.7 Kernel.

[John-Gee]

Oh I am still on 6.6, I'm usually scared of .0 so I have not tried that yet.

If you don't mind me saying, I think it'd be good to note that in the commit and maybe the file too, so that both users like me, but also devs like you in the future, can know why the change was made.

Actually it makes me wonder if you can make the rule depends on the kernel version. I understand people like me are not supported, but this affects LTS users as well.

Thank you!

[ptr1337]

Oh I am still on 6.6, I'm usually scared of .0 so I have not tried that yet.

If you don't mind me saying, I think it'd be good to note that in the commit and maybe the file too, so that both users like me, but also devs like you in the future, can know why the change was made.

Actually it makes me wonder if you can make the rule depends on the kernel version. I understand people like me are not supported, but this affects LTS users as well.

Thank you!

6.7 is pretty okay. Maybe there is some kind of other regression going on? Im not sure.
Sure, I will explain commit messages better and do them via PR.

The regression for nvme's is present through 6.6 also, it is not only 6.7.
We just did recently benchmarks compared to other distros and noted some little regression in the filesystem and stress-ng fork threads, but this seems to be also present on archlinux.
Might be a packaging thing.

[John-Gee]

I appreciate your fast replies and you guys doing benchmarks to keep it all going smoothly!

Thanks a lot!

Do you have a blog or something where we can follow on your tests and progress?

[John-Gee]

With this change: https://git.kernel.dk/cgit/linux/commit/?h=block-deadline&id=e38582207dbf894b18da56981248b1007bd0b675 I'm curious how BFQ will fare in your tests for NVMEs and SSDs.

Although biased, Paolo always seemed to suggest BFQ was it for desktop responsiveness.