the controversy begins re: the BFS scheduler and Con Kolivas

[ThunderRd]

It's starting already. Wonder how long 'til Linus has something to say...

Slashdot Linux Story | Con Kolivas Returns, With a Desktop-Oriented Linux Scheduler

[ccperf721p]

I'm sure it won't be long.

I'm sure it will be poked and prodded until it is a dead project, then someone will steal the code, excuse me, "rewrite the code" leaving out the parts that actually work.

It is the linux purist way, I guess. Maybe if they would dual boot Windows and play some BF2 things would be different. Since there isn't a whole lot of room for big egos in a fair competition things will be the same as they always are.. Trolling and flame wars..


EDIT: We'll see how this turns out, but BSD is starting to look good to me again.

[ThunderRd]

The whole crux of the argument is that the devs want one kernel for all purposes, and CK says that isn't realistic, seeing as the vast majority of users aren't running 8/16/32 etc CPUs...would it really be so bad to have a choice of kernels where one would be more "setup" for your box?

His code should work well for low latencies up to 16 cores, then there's a performance hit.

[ccperf721p]

The argument is invalid in the open source world though. FOSS is not a democracy, the developer of any software can write it any way he desires, if the software doesn't sit well with you, you are free to change any of the code you like.. Once we try to force a dev to do something we want, the entire foundation of open source crumbles..

For all intensive purposes we already have a choice in kernels, by way of various patchsets, including bfs. Upstream development of the 2.6 kernel has been less than impressive, so if a downstream coder wants to take it on and make it work, I'm more for than that than relying on Linus and Co.

[Daniel ~]

If possible, can one of you break this down for me...What does the BFS schedule do and what if any impact will this have for desk top users?

[ccperf721p]

BFS is a cpu scheduler, there are a few different schedulers in the mainstream kernel, such as Deadline, Anticipatory and CFQ.

They basically decide when and what app gets what cycles of the CPU. A desktop that runs multiple apps will need the bandwidth spread out more evenly so that it is very responsive to inputs. A server that runs one app or many CPU's can pretty much run one task until it is finished, then move to the other.

[Gizmo]

To expand on CCPerf's explanation:

The cpu scheduler is the part of the O/S that decides how CPU cycles get allocated. This has an impact on all system operations, as it controls how 'responsive' the system is to particular events.

For a desktop O/S, it is far more important that the forground application (the one the user is in) react quickly to user input than it is that a particular task run to completion without interruption. This is referred to as 'response latency'. The downside to this is the scheduler has to switch tasks more frequently. This results in the O/S spending more time in the kernel and less time handling application processing. This results in increased 'system latency', where a background application may have to wait longer for cpu time because the user is doing something in a foreground app. For a good user experience, though, this is an acceptable tradeoff. It doesn't matter if a particular background task takes a few seconds longer to complete, so long as the USER isn't sitting there waiting for a mouse-click or keypress to be recognized.

For a server app, maximum efficiency is more important than 'response latency', as is equal distribution of cpu cycles. A typical server setup will switch tasks less frequently so as to ensure less time is spent in the kernel and more time processing the applications. In this realm, we want as much cpu time as possible spent running the application, and it's not uncommon for server applications to have 10s to 100s of threads running concurrently, which means that we don't want to waste a lot of resources switching between them.

For embedded applications, it is frequently the case that predictability ('determinism') is the paramount consideration: when a particular task needs to run, it needs to run Right Now. This results in a whole new set of requirements and tradeoffs, many of which are undesirable for either the server or desktop environment.

In addition, the more CPUs (or CPU cores) you are running, the more that high numbers of task switches impact performance. The reason for this is due to the fact that frequently the CPU a task last ran on is not currently available. The scheduler then has to make a choice, make the task wait until its prefered CPU is available or switch the task to another CPU. Switching the task to another CPU is a hugely expensive operation because all of the thread context information and cache data will have to be transferred to the new CPU. If you have an environment optimized for response to the user (a desktop), then it is quite likely you will incur this overhead frequently, especially as you add CPUs. At some point, you are switching between CPUs so frequently that you've lost any response benefit you might have gotten. For servers, you'd rather let the task wait and take advantage of all the cached data on its preferred CPU than to take on all that extra overhead.

That's the gist of what schedulers do. As with any complex problem, there are a number of different ways to approach the problem, and a number of different solutions. Worse, most of the solutions are completely valid for the set of problems they are trying to solve. As a consequence, there isn't any 'right' answer for a generic kernel; only for a particular load.

To complicate matters more, the load that a server experiences might actually CHANGE, meaning that the approapriate scheduler to use a 10 a.m. might not be the appropriate one to use at 10 p.m.

I understand Linus' desire for a single kernel scheduler that can handle all use cases, and I think it might even be possible to eventually get there. I also think that it is foolish to insist on that solution now. There are a number of different ideas floating around in the dev community. Seems to me like we ought to let them air out and see which ones actually prove to be viable. There's no lack of people willing to try them out.

[Daniel ~]

Many thanks guys, I think I have the basic idea.":O}

[cloasters]

Thank you Gizmo and ccperf721p. Great explanations, you guys rule!

[Daniel ~]

Originally Posted by Gizmo

To expand on CCPerf's explanation:

I understand Linus' desire for a single kernel scheduler that can handle all use cases, and I think it might even be possible to eventually get there. I also think that it is foolish to insist on that solution now. There are a number of different ideas floating around in the dev community. Seems to me like we ought to let them air out and see which ones actually prove to be viable. There's no lack of people willing to try them out.

Or as Mint logo states "From freedom came elegance."

[PorPorMe]

Sometimes reading threads like this makes me feel as smart as an earthworm!
I've learned a lot on my own, meaning forums like this and other ways but my left testicle for an education!

[dsio]

At this point in the lkml skirmish, I think Ingo's Johnson is still 5mm longer than Con's. /popcorn.

[ThunderRd]

Originally Posted by dsio

At this point in the lkml skirmish, I think Ingo's Johnson is still 5mm longer than Con's. /popcorn.

Could be, but Ingo may be getting a lot more "strokes"...(atm)...[as I hop over to the mailing list]...

[Daniel ~]

Remember it's not what you have but how badly others use it! (Just to keep a perspective...":O}

[dsio]

Phoronix did a review of BFS that will raise more eyebrows.

[Phoronix] BFS Scheduler Benchmarks