Some Distributions Are Already Making Changes To Linux's Scheduler

[phoronix]

Phoronix: Some Linux Distributions Are Already Making Changes To Linux's Scheduler

Already it's looking like the research from the recently covered The Linux Scheduler: a Decade of Wasted Cores that called out the Linux kernel in being a poor scheduler is having an impact...

http://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-Looks-At-Scheduler

[boxie]

I wonder - Michael - can you graph the P state the CPU is in? i.e. 5 minute test which is really a bunch of 10 second delays and then figuring out what the CPU power level is sitting in?

[Michael_S]

Michael,
You spelled "ClearLinux" as "ClearLinix" by accident at the bottom of the article. Feel free to delete this comment.

[MaxToTheMax]

Scheduler issues only show up when there are lots of workloads happening simultaneously across lots of cores. Isolation benchmarks might not do a good job exposing any problems that exist in the scheduler.

[peppercats]

there's no reason for desktop distros to not use BFS by default, it's all around superior.

[SyXbiT]

there's no reason for desktop distros to not use BFS by default, it's all around superior.

in RHEL7, deadline is the default for all except SATA. CFQ is default for SATA drives.
Many desktops are SATA, so use CFQ. I wonder if it would make sense to not just choose the default based on the disk, but based on if it's a desktop/server.

[Linuxxx]

there's no reason for desktop distros to not use BFS by default, it's all around superior.

Except that it's not...
(lower performance thanks to bouncing threads around every 10ms, not scaling well with increased CPU core count, producing higher frame-latencies, ...)

[unixfan2001]

Except that it's not...
(lower performance thanks to bouncing threads around every 10ms, not scaling well with increased CPU core count, producing higher frame-latencies, ...)

It's a desktop scheduler. It's not as scalable as CFS by design. The bouncing threads are possibly a result of the single run queue, though I doubt 10ms is accurate.
Latency is generally lower than with CFS. With BFS, I never had the problems I had with CFS.

The main contention with BFS would be that it doesn't consider cgroups, at all.

[gamerk2]

The bouncing threads are possibly a result of the single run queue, though I doubt 10ms is accurate.

The "bouncing thread problem" is an issue that shows up a lot on Windows as far as games go. Here's the issue: If you have a high workload thread waiting to run, and a core available to run it, do the benefits of assigning that thread to a different CPU core [requiring data to often be copied across the CPU cache] outweigh the alternative of keeping that thread idle until it's preferred CPU cores free up?

In most cases, at least in games, you want your primary thread(s) running whenever they can. Most programs aren't going to be negatively affected by CPU cache concerns, and leaving high workload threads idle for even a single ms is huge when you consider games have an idea 16ms target render time they are trying to maintain.

At most, the scheduler should try and bias threads to remain on their current core, but in most use cases, if a thread is runnable and there's a core to run it on, there's really not much reason to not have that thread assigned to the available CPU core. Per-core runqueues may solve the bouncing thread problem, but it's not going to give the highest possible performance for workloads that utilize multiple CPU cores with high workload threads.

[caligula]

there's no reason for desktop distros to not use BFS by default, it's all around superior.

What kind of desktop use you had in mind? Some desktop users (Gentoo) compile all the time with 8-16 worker threads or run ffmpeg. Others browse the web. I think the users who develop stuff get better throughput with server grade schedulers.