Is The Linux Kernel Scheduler Worse Than People Realize?

[liam]

The RT kernel should always give you better worst case latency than the cooperative kernel. If it doesn't, something is wrong.

[GreatEmerald]

It's not as simple, because if one core is doing all the works, it may need to crank up its frequency. Still, this is basically what ARM's HI-LO chips do.

Of course. I'm not saying it's simple, I'm saying it needs to be investigated as well, not just performance.

[Linuxxx]

I've recently switched back to CFS from BFS because CFS actually performs better these days, at least for my typical workloads. Core hopping is a serious problem with BFS (under medium load conditions, single-threaded tasks perform like shit because they are being moved to another core every 10ms) - which is almost non-existent with CFS (running a six-core Phenom II here), and using Firefox while compiling something with all cores busy is also not a problem anymore. BFS was great a few years ago when CFS caused serious latency issues under heavy load conditions.

Exactly this!
People need to realize that kernels with BFS and/or activated PREEMPT (like Arch's stock kernel) are actually worse for pretty much everything!
This includes worse maximum latencies and thus more stuttering during gaming.

[Hi-Angel]

I agree linux system development is completely inefficient ,damaging linux system itself. linux development is the real trojan horse of microsoft. developers don''t know the concept of organization of work. They make programs and then they have to adapt their program to match the whole system without a common vision. It's not the right way to organize the work. developers must develop the ability of synergy.

Sorry, I didn't get you. Devs make apps to match an API. Even if API is changed, it is versioned. Things like moving from X11 to Wayland shouldn't touch developers of a usual apps, because communication with underlying window system is the care of tookits, like GTK, Qt, etc.

[s_j_newbury]

I've had some bad experience with buggy software quite a lot of times. Something misbehaves and HDD activity shoots up. Then everything freezes. Sometimes things get back to normal, sometimes I end up restarting the system. I never expected this to happen in a linux machine. I guess this is the problem with the I/O scheduler ?

Sounds like you're running something with a serious memory leak and encountering a "swap storm". Ideally, the system should remain reasonably responsive even in this state, but if your UI blocks waiting for IO which itself is blocked by continuous swap paging it can be like the system has frozen.

[F1esDgSdUTYpm0iy]

I've had some bad experience with buggy software quite a lot of times. Something misbehaves and HDD activity shoots up. Then everything freezes. Sometimes things get back to normal, sometimes I end up restarting the system. I never expected this to happen in a linux machine. I guess this is the problem with the I/O scheduler ?

Try switching to the Liquorix kernel; which defaults to BFQ as an I/O scheduler. I'm quite happy with how that performs. Although, I'd also be curious to know which software would cause you to have to resort to restarting because so far, in the few years that I've been using Linux I've never ran across any such situation.

[Azrael5]

I agree linux system development is completely inefficient ,damaging linux system itself. linux development is the real trojan horse of microsoft. developers don''t know the concept of organization of work. They make programs and then they have to adapt their program to match the whole system without a common vision. It's not the right way to organize the work. developers must develop the ability of synergy.

[jayaura]

What's the default scheduler (can use "dmesg | grep scheduler" to find out)? If it's noop or deadline (Ubuntu defaults to deadline), then (from what I've seen), anything that uses the HDD pretty hard can cause other things to freeze up for a bit, including the mouse

[    0.392416] io scheduler noop registered
[    0.392419] io scheduler deadline registered
[    0.392446] io scheduler cfq registered (default)

Its the default scheduler I suppose. Maybe BFS / ck patches might help ?

I've had some bad experience with buggy software quite a lot of times. Something misbehaves and HDD activity shoots up. Then everything freezes. Sometimes things get back to normal, sometimes I end up restarting the system. I never expected this to happen in a linux machine. I guess this is the problem with the I/O scheduler ?

What's the default scheduler (can use "dmesg | grep scheduler" to find out)? If it's noop or deadline (Ubuntu defaults to deadline), then (from what I've seen), anything that uses the HDD pretty hard can cause other things to freeze up for a bit, including the mouse

[jayaura]

I've had some bad experience with buggy software quite a lot of times. Something misbehaves and HDD activity shoots up. Then everything freezes. Sometimes things get back to normal, sometimes I end up restarting the system. I never expected this to happen in a linux machine. I guess this is the problem with the I/O scheduler ?