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

RealNC

09-04-2009, 06:42 PM

(Michael, I hope you will be able to make a frontpage news item out of this one :))

I recently stumbled upon an LWN article that mentioned Con Kolivas is working on a new kernel scheduler for Desktop/Multimedia/Gaming PCs called "BFS":

http://lwn.net/Articles/350100

Well, I've tried it. I wrote my experiences with it here:

http://lwn.net/Articles/350820

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.

The patch to kernel 2.6.30 and docs can be found at:

http://ck.kolivas.org/patches/bfs

Edit:
206 was a regression and has been pulled again. If anyone is going to try this, use 205. If you tried 206 (and experienced the extreme stalls) use 205 instead.

L33F3R

09-05-2009, 02:17 AM

interesting concept good sir. Glad to hear you had a positive experience.

kraftman

09-05-2009, 02:43 AM

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.

RealNC

09-05-2009, 03:22 AM

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.

kraftman

09-05-2009, 03:58 AM

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 :o (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.

deanjo

09-05-2009, 07:24 AM

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.

deanjo

09-05-2009, 10:39 AM

Heh I like that he included this in the repo:

http://ck.kolivas.org/patches/bfs/supported_features.png

So true..

Ant P.

09-05-2009, 11:46 AM

RealNC

09-05-2009, 02:43 PM

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.)

kraftman

09-08-2009, 07:43 AM

It seems bfs is a mess:

http://marc.info/?l=linux-kernel&m=125227082723350&w=2

@RealNC

I really recommend you to try a normal distro (with sane config...), before you post a thing, because it seems you've got something really messed up...

@Ant P.

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%.Strange, because I have no problems with CPU usage. It seems two Gentoo users have problems.

@Deanjo

EDIT:

Deleted my bull xd

However, flash problems are flash problems :>

RealNC

09-08-2009, 10:55 AM

It seems bfs is a mess:

http://marc.info/?l=linux-kernel&m=125227082723350&w=2

@RealNC

I really recommend you to try a normal distro (with sane config...), before you post a thing, because it seems you've got something really messed up...

I know how to configure a kernel. And I had those problems with openSUSE too.

@Ant P.

Strange, because I have no problems with CPU usage. It seems two Gentoo users have problems.

Way to extrapolate. "I have no problems therefore the rest of the world doesn't either."

(Snipped the rest of this nonsense.)

I recommend reading up on this issue because I'm in no mood to start googling and copy&pasting for you. This issue has been there since the first time Kolivas solved it with his -ck tree (which got largely ignored by most devs since their so-called "desktop" consists of an xterm and emacs running on 10000$ hardware.) He worked hard and got far. Hearing this from you is insulting his much appreciated work. Also read up on the extreme performance gains Android users get with BFS.

Ant P.

09-08-2009, 12:21 PM

That's an awful lot of rhetoric coming from someone who doesn't know what they're talking about. Insulting my choice of distro? Ugh, grow up.

kraftman

09-08-2009, 01:12 PM

I know how to configure a kernel. And I had those problems with openSUSE too.

Way to extrapolate. "I have no problems therefore the rest of the world doesn't either."

(Snipped the rest of this nonsense.)

I wonder, because you had problems even with Alsa. "I have problems therefore the rest of the world also does". Oh, where's your config? :>

I recommend reading up on this issue because I'm in no mood to start googling and copy&pasting for you. This issue has been there since the first time Kolivas solved it with his -ck tree (which got largely ignored by most devs since their so-called "desktop" consists of an xterm and emacs running on 10000$ hardware.) He worked hard and got far. Hearing this from you is insulting his much appreciated work. Also read up on the extreme performance gains Android users get with BFS.I will try myself, but CFS does job very well here. I don't appreciate this mans work. However, it can change ;)

@Ant P.

That's an awful lot of rhetoric coming from someone who doesn't know what they're talking about. Insulting my choice of distro? Ugh, grow up.The point is it can be something wrong with your config. Eh, who's talking about?

Oh, I probably know what you mean, but I prefer to see improvements on paper, because I don't believe in Con's sixth sense.

Ant P.

09-08-2009, 01:16 PM

@Ant P.

The point is it can be something wrong with your config. Eh, who's talking about?

Oh, I probably know what you mean, but I prefer to see improvements on paper, because I don't believe in Con's sixth sense.

I'm talking about a process going from taking 18 hours to run to 12 hours.

Or are you saying all the Folding@Home users on Ubuntu, Kubuntu, Fedora, Arch also have a "broken config" too?

kraftman

09-08-2009, 01:19 PM

I'm talking about a process going from taking 18 hours to run to 12 hours.

Or are you saying all the Folding@Home users on Ubuntu, Kubuntu, Fedora, Arch also have a "broken config" too?

In Ingo's benchmarks CFS does much better. I would appreciate if you can show me some links. Links related to those reports you mentioned. Btw. something good can result from comparing those two schedulers, because Ingo is open for improvements.

Ant P.

09-08-2009, 01:24 PM

In Ingo's benchmarks CFS does much better. I would appreciate if you can show me some links.

Okay. Here's some real world numbers (http://foldingforum.org/viewtopic.php?f=44&t=11336), perhaps now you can also show some links where CFS is better outside of cherry-picked benchmarks?

RealNC

09-08-2009, 01:28 PM

If you are not affected by this issue, there's no reason to participate in solving it. This is not a court and we don't have to prove to you that we're not lying.

nanonyme

09-08-2009, 01:34 PM

If you are not affected by this issue, there's no reason to participate in solving it. This is not a court and we don't have to prove to you that we're not lying.So only the other party needs to give proof to back up their point of views? ;) Sounds like an interesting "debate".

kraftman

09-08-2009, 01:38 PM

If you are not affected by this issue, there's no reason to participate in solving it. This is not a court and we don't have to prove to you that we're not lying.

I'm sure nobody's lying here, but some problems can be related to something else.

@Ant P.

It seems this person ran RT kernel, some other people were using default settings. There's nothing interesting.

...perhaps now you can also show some links where CFS is better outside of cherry-picked benchmarks?It seems Ingo's benchmarks are quite objective. The most interesting would be Con's benchmark results. However, I can realize it's hard to measure some things.

Btw. someone noticed:

http://marc.info/?l=linux-kernel&m=125243507622544&w=2 :>

Ant P.

09-08-2009, 01:42 PM

Oh well, all I can do is demonstrate a 50% performance improvement. I can't cure blind fanboyism from people who refuse to even look for themselves, and so I am done in this thread.

kraftman

09-08-2009, 01:49 PM

Oh well, all I can do is demonstrate a 50% performance improvement. I can't cure blind fanboyism from people who refuse to even look for themselves, and so I am done in this thread.

Well, Ingo showed even 90.1% CFS performance advantage over BFS... Fanboism you say?

RealNC

09-08-2009, 02:03 PM

I posted proof on lkml. See the latencytop and tracing results. Also, with so many people confirming, this must be a cabal/conspiracy to destroy the mainline scheduler, right? :P

Seriously. Con's code helps *immensely* not only here, but elsewhere too (the Android guys are having multiple orgasms already, and obviously they're not using Gentoo.)

kraftman

09-08-2009, 02:13 PM

I posted proof on lkml. See the latencytop and tracing results. Also, with so many people confirming, this must be a cabal/conspiracy to destroy the mainline scheduler, right? :P

Heh, this is what I thought ;) (don't forget some note in wikipedia ;p).

Seriously. Con's code helps *immensely* not only here, but elsewhere too (the Android guys are having multiple orgasms already, and obviously they're not using Gentoo.)Let's hope devs will do everything to make things better. I just don't like when people base their opinions on something weak (I'm not according to you). P.S. mentioning Gentoo I thought only about custom configs, I'm not saying there's something wrong with it.

L33F3R

09-09-2009, 06:54 PM

the Android guys are having multiple orgasms already, and obviously they're not using Gentoo.)

Woahhhh hold on Johnson. Someone tell me whats going on here.

AdrenalineJunky

09-09-2009, 09:38 PM

deanjo

09-09-2009, 10:30 PM

kraftman

09-10-2009, 03:10 AM

i would like to point out that ingo's test hardware puts it at the highest point Con said he thought it would scale too.... a 16 thread machine...

this is meant as a *desktop* scheduler, a dual quad core hyper-threading system is not exactly a typical desktop PC.

There's no doubt CFS beats BFS in performance (shouldn't bfs be better from beginning and then just drastically choke when more cores are involved? I do not know, but maybe all cores were used from begining hmm...), but what counts the most on desktops is responsiveness and this is what someone should measure.

Kano

09-10-2009, 03:12 AM

Just compiled a .31 final kernel with bfs 211 patch and it crashed after a few minutes. Does not seem to be that stable yet.

BlackStar

09-10-2009, 03:14 AM

Ya, I kinda snickered at that too.

Ingo may not have meant it like this, but using such hardware really felt like a deliberate attempt to disprove Con's scheduler.

I'm on the fence about this issue, since I haven't really felt any issues with the current scheduler, but if the improvements on single-, dual-, tri- and quad-core systems are repeatable (you know, the hardware desktop PCs actually *have*), then we might have something good on our hands.

The issue is that kernel devs are (rightly) extremely resistant to change on this area. However, if this shows so significant improvements that Android and other distros adapt it (despite being an out of tree patch), we will likely see one of two things:
1. This makes it into the kernel. (Patch from Con? Yeah, right...)
2. CFS is improved to match BFS on the desktop.

Both outcomes are good from my point of view!

kraftman

09-10-2009, 03:33 AM

1. This makes it into the kernel. (Patch from Con? Yeah, right...)

Who knows? ;) However, distros can provide bsf patched kernels (not default ones, but can gave opportunity to install such kernels from repos).

2. CFS is improved to match BFS on the desktop.This is what's actually going on and if they fix issues which some people report bfs probably won't be interesting.

http://marc.info/?t=125227083800005&r=1&w=2

Even Con replied :>

RealNC

09-10-2009, 03:42 AM

Woahhhh hold on Johnson. Someone tell me whats going on here.

Google for "Android BFS Kernel". The BFS-enabled firmware is called "Cyanogen" I think (or maybe it's the nick of the dude who maintains it, dunno.)

Note that BFS is actually not a ready or even released project. It's just a proof-of-concept at this point. It was able to boot on the machine it has been developed on only 15 days ago, with development starting from scratch about 20 days ago. So you do the math how "ready" it is :P

deanjo

09-10-2009, 07:39 AM

Ingo may not have meant it like this, but using such hardware really felt like a deliberate attempt to disprove Con's scheduler.

That it did, but it's not the first time that the kernel devs and distro's seemed to have thought that desktop=workstation/server.

kraftman

09-10-2009, 09:10 AM

That it did, but it's not the first time that the kernel devs and distro's seemed to have thought that desktop=workstation/server.

So I prefer workstation/server scheduler, because it doesn't choke like Windows one. When was this second time? When they replaced thing called SD which caused Tux racer to be unplayable and sound to stutter? If Con doesn't agree with Ingo's results he just should show some counter-results (if there's a way to measure some things...). This would be sane. There's always possibility BFS is better in some things (and it solved some people problems, so it's good because bfs brought more attention to some things).

RealNC

09-10-2009, 01:29 PM

So I prefer workstation/server scheduler, because it doesn't choke like Windows one.

Actually, Windows turns out to be pretty good at this stuff now. Unless you mean Windows 95 :P

Anyway, BFS was not created to replace mainline. It was created just to prove a point: When someone complained about lagging windows, compositing and such, the answer you got was "that's because X sucks, it's not made for multimedia desktops". I thought that too (also blamed fglrx, but it turns out, BFS fixed problems I blamed on fglrx, like mplayer dropping frames when I moved the window around or rotated KDE's desktop cube). Con wrote BFS and people realized "holy crap, it *is* the kernel's fault!"

So in a sense, Kolivas won ;)

kraftman

09-10-2009, 01:56 PM

So in a sense, Kolivas won ;)

But it seems BFS lost and CFS won (you know, don't you? ^^). Kolivas indirectly helped to catch some bug, but you helped directly :> This is great :)

Some people can be disappointed, because it seems all those things they were talking about CFS are just myths and FUD :D

However, I never had problems you described :>

RealNC

09-10-2009, 02:26 PM

But it seems BFS lost and CFS won (you know, don't you? ^^). Kolivas indirectly helped to catch some bug, but you helped directly :> This is great :)

Well, I've just run the tests I was told to run by Ingo and others. If Con hadn't written BFS, most people would have simply assumed that the GUI lag is Compiz'/KDE's/X.Org's/Catalyst's fault instead of the kernel's.

Some people can be disappointed, because it seems all those things they were talking about CFS are just myths and FUD :D

Nevertheless they should be happy if it gets fixed for good.

However, I never had problems you described :>

Do you have composite enabled? (Compiz/KDE4 etc). The problem mostly manifests with composite effects since the compositor is competing for interactivity with the applications it is actually compositing. If I turn off desktop effects, I also don't have any issues :P

kraftman

09-10-2009, 02:39 PM

Do you have composite enabled? (Compiz/KDE4 etc). The problem mostly manifests with composite effects since the compositor is competing for interactivity with the applications it is actually compositing. If I turn off desktop effects, I also don't have any issues :P

Yes, I have KDE 4 composition enabled and I can switch smplayer with Amarok etc. using alt+tab and it works excellent :) Music is playing same time and I can even run OpenSSL test :) However, I'm using open source radeon driver and maybe this helps in some part.

EDIT:

Ooops, sorry. I can benchmark OpenSSL, but I must have composition disabled, because movie isn't smooth then.

RealNC

09-10-2009, 02:53 PM

Zhick

09-10-2009, 03:08 PM

Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?).
Hey I'm experiencing exactly that. Interesting to see the scheduler is at fault.
Is there a easy way to disably this NEW_FAIR_SLEEPERS you're talking about? Kernel-rebuild would be ok, but I'm stuck at 2.6.28 (fglrx 9-3) so an update wouldn't be possible.

RealNC

09-10-2009, 03:15 PM

It's not configurable by means of "make menuconfig" and such, but it's still easy. From inside the kernel source tree, open "kernel/sched_features.h" in an editor and the first line there should be:

SCHED_FEAT(NEW_FAIR_SLEEPERS, 1)

Replace the 1 with a 0 there. Then simply rebuild the kernel and boot it.

kraftman

09-10-2009, 03:24 PM

OK, last test:

Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?)

Yes I have Oxygen widget style selected. Using gl2(yuv) in SMplayer menus are corrupted:

http://img34.imageshack.us/img34/6769/zrzutekranu1o.png

however, when I'm switching menus using this mode movie is smooth, but I have problems you described using xv (0 - Radeon Textured Video). With xv (I used this all time) it's smooth. Maybe with BFS or using NO_NEW_FAIR_SLEEPERS Radeon Textured Video will be fine now (except corrupted menus of course ;))? We'll see :)

And, are you on an AMD or Core I5/I7 CPU?I have Athlon X2 64 5000+.

RealNC

09-10-2009, 03:26 PM

Hmm, another AMD user who doesn't have most of those issues. It looks more and more like Intel Core 2 and Pentium owners are the most affected for some reason.

Or it could be coincidence :P

kraftman

09-10-2009, 03:30 PM

Hmm, another AMD user who doesn't have most of those issues. It looks more and more like Intel Core 2 and Pentium owners are the most affected for some reason.

Or it could be coincidence :P

Sabotage! AMD processor has some problems using RADEON textured video and open source RADEON drivers ;)

I wonder if this change in scheduler will affect benchmarks?

And I meant win xp before. When running Boinc it was a pain on Duron 850Mhz and on Linux it was just alright.

suokko

09-11-2009, 04:08 AM

OK, last test:

Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?)

And, are you on an AMD or Core I5/I7 CPU?

PS:
I also ran tests with the open source drivers.

Does oxygen call exaTrapezoid a lot? For me at least that eats a lot of cpu time in xserver which is single threaded so it will cause XV slowdown because they hav to share the cpu time with in xserver.

You can find out what is taking cpu time in menus with sysprofile running a profile while you open and close menus for an half minute.

Gnome does use trapezoids a lot which makes gtk very slow. Too bad trapezoids are hard to gpu accelerate so if you are good at drawing smooth lines patches are welcome to add GPU accerlation to open drivers.

Svartalf

09-11-2009, 08:34 AM

Just compiled a .31 final kernel with bfs 211 patch and it crashed after a few minutes. Does not seem to be that stable yet.

It's a bit of experimental code... I'd not expect it to be all that stable, Kano... ;)

Svartalf

09-11-2009, 08:55 AM

Ingo may not have meant it like this, but using such hardware really felt like a deliberate attempt to disprove Con's scheduler.

I'm pretty sure Ingo didn't mean it like that- but unfortunately, everyone over there in LKML appear to have fallen for the "lowest RMS error" folly. If you're doing server stuff, yeah, in the large, you want what Ingo's talking to. However, once you introduce a UI, text or graphic, the rules should change a bit.

I'm on the fence about this issue, since I haven't really felt any issues with the current scheduler, but if the improvements on single-, dual-, tri- and quad-core systems are repeatable (you know, the hardware desktop PCs actually *have*), then we might have something good on our hands.

There IS an issue with what we've got as the default. It's not as interactive as the old way of doing things. But, in the same vein, I'm concuring with Con on BFS- it's a demo to show there IS an issue and there can be considerable room for improvement. Ingo and the others are going "but the latency..." not realizing that some latencies are actually needed because humans don't work in lock-step with how the computer works. We have a sliding window atom of attention of about 100msec. If you catch things just right, they seem fluid and are "snappy". Miss the window in the wrong way (and there's several of them...try talking with a delay-line of 150msec applied to what you hear of your speech...) and things feel "laggy" at the least, if not worse. With the introduction of CFS and a few other things, while the overall base performance is impressive, the interactivity suffers while under load.

The issue is that kernel devs are (rightly) extremely resistant to change on this area. However, if this shows so significant improvements that Android and other distros adapt it (despite being an out of tree patch), we will likely see one of two things:
1. This makes it into the kernel. (Patch from Con? Yeah, right...)
2. CFS is improved to match BFS on the desktop.

I think Con's actually trying to get #2 to happen. That's his stated goals with BFS. He's making it so it largely works, but would be nothing that the kernel crowd would accept into the tree unless there was something like pluggable scheduler modules. And it does seem to show real improvements in interactivity (Even Ingo observed this much...)- only a slight degredation in some areas (Which is where much of the issue at the moment lies- everyone's worrying about lowest latency, which is good, but how they're getting it sacrifices interactivity). For a desktop or handheld device, I suspect once he works the bulk of the kinks out there'll be some more serious looking at what he's trying to tell everyone (yet again...). I'm hoping Ingo takes the hint here and looks into what he missed on CFS and comes up with improvements or an "acceptable" answer to what Con's showing us right now.

Svartalf

09-11-2009, 08:57 AM

Gnome does use trapezoids a lot which makes gtk very slow. Too bad trapezoids are hard to gpu accelerate so if you are good at drawing smooth lines patches are welcome to add GPU accerlation to open drivers.

Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.

kraftman

09-11-2009, 08:59 AM

@Sfartalf

Everything should be fine:

http://lkml.org/lkml/2009/9/10/229

suokko

09-11-2009, 09:55 AM

Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.

Except that GPU rendering doesn't exactly match the X requirements so you would have to do it with shaders.

Michael

09-11-2009, 10:03 AM

BFS benchmarks coming next week off 2.6.31 final.

L33F3R

09-11-2009, 11:08 AM

@Svartalf: Trippppple Kill

@Michael: Thanks. I eagerly anticipate this 1 :)

RealNC

09-11-2009, 11:40 AM

BFS benchmarks coming next week off 2.6.31 final.

Please don't forget to also check with mainline but with NEW_FAIR_SLEEPERS disabled. I assume that kernel debug features will be disabled for benchmarks, so to disable that option you can simply change the default from 1 to 0 in kernel/sched_features.h.

PS:
I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.

StringCheesian

09-11-2009, 12:29 PM

Please don't forget to also check with mainline but with NEW_FAIR_SLEEPERS disabled. I assume that kernel debug features will be disabled for benchmarks, so to disable that option you can simply change the default from 1 to 0 in kernel/sched_features.h.

PS:
I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.

I've seen rumors of BFS significantly decreasing compile times. Something like "BFS turned a 12 hour compile into 10 hours!!!" - I forget where I saw it.

He could also do FPS and gtkperf benches with a background process burning cpu, or something like that.

RealNC

09-11-2009, 12:39 PM

I've seen rumors of BFS significantly decreasing compile times. Something like "BFS turned a 12 hour compile into 10 hours!!!" - I forget where I saw it.

This is due to a regression in mainline where CPUs are under-utilized. For example a "make -j2" in dual-core machine only uses about 90% CPU. BFS uses 100% so yes, it finishes faster. Not sure if everyone is affected here.

He could also do FPS and gtkperf benches with a background process burning cpu, or something like that.

That one is actually pretty much the whole point of BFS.

kraftman

09-11-2009, 12:40 PM

PS:
I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.

Actually it can. BFS is "faster" here in pgbech, but I tested CFS in KDE terminal (and NEW_FAIR_SLEEPERS were enabled) and BFS only in vt (DE was not running), because I have some issues with it in graphical environment. There are also problems with BFS like some processes get caught in infinite loops.

CFS with NEW_FAIR_SLEEPERS disabled should perform better in my opinion. Those problems with compilation times were also addressed.

That one is actually pretty much the whole point of BFS

The same about CFS. Just some issues had to be fixed :)

deanjo

09-11-2009, 01:06 PM

The same about CFS. Just some issues had to be fixed :)

That's why it's always good to have alternatives and people "challenging" the system. Chances are if BFS didn't come around regressions (if it is even a regression or it was just broken from the start) probably wouldn't have been addressed in CFS for quite some time.

kraftman

09-11-2009, 02:09 PM

That's why it's always good to have alternatives and people "challenging" the system. Chances are if BFS didn't come around regressions (if it is even a regression or it was just broken from the start) probably wouldn't have been addressed in CFS for quite some time.

Yes, I completely agree. This is great.

Reading some forums it seems mainly Intel CPUs have those problems. Like RealNC said.

kraftman

09-13-2009, 10:06 AM

Someone should measure graphic performance, because it's something very important on desktops (yeah, I know, but I believe there will be some games on Linux someday ;)). In Urban Terror I have double more FPS using CFS scheduler then with BFS (Amarok must be running same time!!! if I run only UT it seems FPS amount is the same). BFS also kills my input sometimes.

When comes to compilation time BFS does better, but with *Sleepers* disabled in CFS it should be at least as good as BFS. Whatever Phoronix results will be, it seems it won't be fair comparison. BFS "ignores" just too many things which drives to dead input, processes and thus it can be "faster" in some benchmarks. It will be great to see fixed CFS vs more mature BFS results someday.

P.S. I used generic Arch Linux kernel vs BFS patched kernel from AUR.

Btw. with NO_NEW_FAIR_SLEEPERS pgbench result is much lower (BFS : CFS : CFS_NNFS using debugfs) - 1650 : 1350 : 935 +/-.