If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Announcement

Collapse

No announcement yet.

Con Kolivas is working on a new scheduler for Desktop/Multimedia/Gaming PCs

If you're feeling adventurous, you might want to give that one a try. In my case, it helped immensely, especially with sound latency and skips and other artifacts during real-time playback (I was not using an RT kernel before that though). Note that BFS has been updated to 0.205 since I wrote that.

Comment

If you're feeling adventurous, you might want to give that one a try. In my case, it helped immensely, especially with sound latency and skips and other artifacts during real-time playback (I was not using an RT kernel before that though).

Maybe you should use RT kernel or you just had messed up config? I have standard Arch Linux kernel (300Hz) and when I benchmark OpenSSL performance (both cores near 100% each) I have no single latency in lmms. I remember you had some problems with ALSA, so it seems problem with kernel config...

From Con's FAQ: "Because it's designed in such a way that mainline would never be interested in adopting it, which is how I like it."

EDIT:

BFS supports NUMA, sorry for confusion....... and while SD was pain I never tried -CK patched kernel.

Comment

Maybe you should use RT kernel or you just had messed up config? I have standard Arch Linux kernel (300Hz) and when I benchmark OpenSSL performance (both cores near 100% each) I have no single latency in lmms.

lol. With 300Hz that means you're as perceptive as a turtle. No offense.

Comment

lol. With 300Hz that means you're as perceptive as a turtle. No offense.

Probably I do not notice any latencies (maybe because I'm hardcore turn based strategy gamer ). However, I think some other config options are more important - one time I broke my kernel and even mouse cursor stuttered (everything was to minimize latencies in my feeling, but it behave exactly opposite). Btw. distros should tune kernel, scheduler (CFS should be quite good) to do well on desktops.

Comment

Lol, good to see Con come back but it sounds like he still is pretty ticked off about the past. From the FAQ:

Why "Brain Fuck"?

Because it throws out everything about what we know is good about how to
design a modern scheduler in scalability.
Because it's so ridiculously simple.
Because it performs so ridiculously well on what it's good at despite being
that simple.
Because it's designed in such a way that mainline would never be interested
in adopting it, which is how I like it.
Because it will make people sit up and take notice of where the problems are
in the current design.
Because it throws out the philosophy that one scheduler fits all and shows
that you can do a -lot- better with a scheduler designed for a particular
purpose. I don't want to use a steamroller to crack nuts.
Because it actually means that more CPUs means better latencies.
Because I must be fucked in the head to be working on this again.
I'll think of some more becauses later.

Comment

Been using it for a week. I don't notice any difference in interactive stuff, but my PC's already fast.

What I DO notice is that CPU-intensive things (emerge, folding-at-home, etc.) run a hell of a lot faster. I can actually max out all my cores now whereas on CFS I'd always get less than 100%.

With all due respect to Ingo and Linus, if I can't max out my CPU on a CPU-bound non-interactive program just because of your scheduler, then your scheduler sucks horribly.

I noticed that too. For example, a kernel build with "make -j2" now finishes faster than -j2 or -j3 did before. With -j2 I get 100% CPU load now. Before, even with -j8 the CPU load was 95-97%. And the funny thing, even though now load is maxed out, the desktop stays responsive. Before, even if it wouldn't max out the CPU, the desktop would lag.

Also, another thing is that moving an mplayer window around doesn't result in the video skipping anymore; the video always plays smooth no matter if you move the window or not (just like in MS Windows.)

However, the Catalyst (fglrx) drivers have problems with this scheduler. OpenGL apps tend to hang and can't be killed. Con suspects a race condition in the Catalyst drivers that are brought forward by the scheduler (as he already suspected and wrote about in the FAQ.)