Paper: www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf
Extended slides: www.i3s.unice.fr/~jplozi/wastedcores/files/extended_talk.pdf
Patches (updated): github.com/Freeaqingme/wastedcores

Or maybe I should have opened an issue on Zen directly?

Cheers
Back to top

I think this is a great attempt at improving core balancing on CFS.

Of all schedulers, BFS is the most balanced but the least efficient, since it takes the approach at a grocery stores where you have one line to multiple cash registers. CFS is like a grocery store where anyone can choose any lane, but instead you have someone checking the lanes and moving people based on some type of criteria.

These guys basically changed the algorithm / heuristics using their own synthetic tests, which is great! Changes made off of data are usually better than tests done, because it seems right.

I didn't know that the authors of the paper refreshed their patches against the latest stable kernel, I'll try applying them and getting them up for everyone to use soon.
Back to top

Wow, that was fast.

Not sure how to properly test this now though. :)
Back to top

How does this brake BFS?
Back to top

Great to see you managed to fix BFS build again. Kudos!

Does that mean "wastedcores" patches are back in again?
Back to top

Hi guys, sorry for the delay, I've just been busy and haven't had much time to spend lately on Liquorix.

So, I thought that wastedcores broke the BFS build because I merged it when I also merged the stable-queue patches for the next version of the 4.5.x series. However, it was actually a stable kernel patch that introduced a micro-optimization that disabled debugging functionality until one had explicitely turned it on (CONFIG_SCHEDSTATS).

I merged a patch to zen-kernel to fix the most immediate build bug:

github.com/zen-kernel/zen-kernel/commit/27c58ca020852ab2e2fa56eb89a1c4490626d068



But, regardless of whether we could build the wastedcores patch set, more discussion came out on LKML where the primary maintainers of the schedulers determined that there were no wins on common hardware, in fact even on a NUMA system, they the behavior of the scheduler did not change. Apparently, the developers of this patch set had a very unique system that is inefficient in its design, and most people, even in enterprise, won't ever run into an issue.

So, this patch set will not be remerged unless the authors make a change that improves performance that other authors of CFS can verify.
Back to top