BFS Scheduler Lost Some Charm With Linux 3.11

[mgmartin]

I'm on Fedora 20 amd64 and a few days ago my PC started hugely stuttering (the mouse and even the music playing in the background!) while I was finishing copying 11GB of data to a 16GB USB flash drive.

Writing several gigs to slow usb was a major issue for me too. After reading this article: http://www.novell.com/support/kb/doc.php?id=7010287 and setting a few limits in my /etc/sysctl.conf, things got much better for me.

vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 104857600

[mark45]

It seems you have never tried Windows 7... because AFAIK this affects all operating systems, and it's due to hard disk throughput. Just buy a SSD and see the difference for yourself. It probably could be improved but I guess the kernel devs don't really care since Linus uses a SSD

I have win7 amd64 on same PC - it's ok.
It only affects Linux, and it's not the HDD (sata III) to blame, its thruput in real life/usage is about 35-45MB/s while the USB flash drive ~10 MB/s.

[AnonymousCoward]

I honestly haven't had any responsiveness issues in a long time for either CFS or when I was testing BFS. Certainly YMMV of course but it's solid for both my laptop and desktop for at least 2+ years. I remember it being a serious problem back before CFS, though, way back when we had staircase, nicksched as alternatives as well as the 64bit iosched bugs, but they don't appear to be a problem on my systems anymore.

[DrYak]

There we go again, Michael, it's not about speed, it's about responsiveness.

I'm on Fedora 20 amd64 and a few days ago my PC started hugely stuttering (the mouse and even the music playing in the background!) while I was finishing copying 11GB of data to a 16GB USB flash drive.
{...} I guess the default Linux scheduler is part of this pathetic behaviour.

It's not even a "pathetic behaviour", its by design.

With scheduler, you have a trade-off between performance and responsiveness.
(One of the simplest way to understand: if you perform more switch between tasks, tasks respond quicker and you get the feeling that the system is performing "faster", even if actually the system is actually wasting time on task-switching.
A performance-oriented scheduler will try to finish tasks as faster as possible even if that means that some task will have to wait a little bit longer (but the current task won't, for exemple, lose time because of harddisk seeks).
A responsiveness-oriented scheduler will try to make sure that "events" are handled and answered as quick as possible even if that means that the current task will get interrupted a lot which will overall cost time).

CFS and BFS are also at different points on the performance vs. responsiveness tradeoff.
if CFS is faster, it will be by design less responsive (because it tries to finish task sooner, instead of constantly pausing them, switching to other, handling event, switching back and resuming).
if BFS is more responsive, it will be slower by design (it will do the constant interruption of tasks).

It seems you have never tried Windows 7... because AFAIK this affects all operating systems, and it's due to hard disk throughput. Just buy a SSD and see the difference for yourself. It probably could be improved but I guess the kernel devs don't really care since Linus uses a SSD

Theoretically, it should be possible to interrupt more frequently the current copying task, so other task get a chance at the limited throughput and don't slow down the whole system. (But that will come at performance costs, because the copying task will be more frequently interrupted and will lose time because of resyncs).
Or in the above's exemple, you should schedule the IO on the USB bus so that the mouse gets polled frequently enough to be responsive (even if that means that the data transfer to the USB stick will get interrupted more often and you won't reach maximal throughput. The copy will take more time, but the mouse will answer imediately).
(Well in the "copy to USB" example, if the machine has enough USB ports, it might be possible to chance connections so that mouse and USB drive are on separate USB buses and don't fight each other over the limited USB bandwidth and latency).


On Windows 7, you're pretty much hosed (except for changing ports as suggested).
On Linux, you've got a pretty big zoo of different schedulers and interrupt frequencies to find the sweet spot which most probably suits your needs.
(Typical Servers will go for the "try to finish task as soon as possible". Tolerate small delays in answers if that means will work overall faster.
Typical Desktop will go for the "constantly interrupt everything". Sacrifice speed to make sure that interrections between user and machine are answered as fast as possible).

[tiredoffglrx]

I am sorry, but to those saying that scheduling is worse under Windows: You've clearly never tried to do any work under heavy disk usage in Linux. Here, try this use case:

Download photorec and let it restore deleted files from one partition to another. Then try to move your mouse, open some applications, type something in. The waiting times are unacceptable! On my system (12.04 LTS, Kernel 3.12) I can't even move the mouse properly! This never happens with Windows. The CPU and disk usage might be as high as they want, you will always be able to move your mouse and kill the offending application, if necessary.

Before switching to the mainline 3.12 kernel I had the Con Kolivas patch-set with BFS and BFQ running. The difference in responsiveness was incredible. I am sorry but I just can't see how this is hard to quantify. Just put the system under heavy CPU/IO load and measure the time between performing an action and seeing the response (e.g. launching a terminal, switching to TTY, so many possibilities). If you don't see the difference you are either in denial or using a monster of a PC. The only reason I am back on the mainline kernel is because the patch-set isn't optimized for notebooks and was drawing more power.

These issues with responsiveness are my number one problem with Linux. I can live with bugs in the UI here and there but to see this core system issue stay unfixed for five years now is mind-boggling to me. Linus wants desktop Linux to succeed. Then why not put more resources into fixing one of Linux' most deal-breaking problems!? And if there's a trade-off between performance and responsiveness why not make sure that the kernel can be configured towards either end by distributions?

[lano1106]

CFS and BFS are also at different points on the performance vs. responsiveness tradeoff.
if CFS is faster, it will be by design less responsive (because it tries to finish task sooner, instead of constantly pausing them, switching to other, handling event, switching back and resuming).
if BFS is more responsive, it will be slower by design (it will do the constant interruption of tasks).

I like very much your reply. However, I disagree a bit on this.

CFS tries to be good in all situations by using a lot of heuristic logic

ie: Detecting the type of process (i/o bound, cpu bound)
Adjusting timeslices dynamically and so on

BFS is very simple and has been designed specifically to be good in typical desktop load.

With desktop loads, it has been demonstrated that BFS is still more responsive *and* faster than CFS. Just step out a little bit of the "typical" desktop load and then CFS will perform better.

[Rallos Zek]

Ok. O(C) with whatever C value you want. If not please enligth us with your knowledge.

What? I was not the one who made a false statement about CFS.

[Rallos Zek]

BFS is not worth the effort to install at this point , heck even Liquorix performance kernel stopped using it because all of the bugs it caused and the non effect it has on desktop responsiveness.

BFS did make things smoother on the desktop a few years back I will admit, but lately its been noticeably slower and really buggy.

Kudos to Con for helping to move the kernel forward, and I hope he does find and fixes the bugs in BFS.

[jakubo]

im not sure, but it sounds like there is some buffer problem, or missing. why would a clearly set task ("copy this there") need so many calls to the CPU? this sounds very uneffective to me.
is this related to benchmarks with the disk tools on ubuntu? you can see the curve drop quite strongly. Why is that?

[a user]

There we go again, Michael, it's not about speed, it's about responsiveness.

I'm on Fedora 20 amd64 and a few days ago my PC started hugely stuttering (the mouse and even the music playing in the background!) while I was finishing copying 11GB of data to a 16GB USB flash drive.
And that's without doing anything in the background and it's got 4GB of RAM & Intel Core i5, I guess the default Linux scheduler is part of this pathetic behaviour.

I'd love to try out BFS to see if it fixes this bug #1 on Linux which has been there for ages, there are even songs about it, not kidding.

So I don't give a flying fuck if BFS is a little slower, responsiveness is what kills the Linux desktop experience.

i am yet to experience this so called bug number one since i am running linux (>12 years).