# Brain Fsck Scheduler

## Naib

http://ck.kolivas.org/patches/bfs/bfs-faq.txt

anyone tried it? 

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

im abt to patch latest kernel to see

----------

## ToeiRei

I remember Con Kovalis quitting kernel development about roughly 2 years ago for some reasons. He was the one doing straight logic and really good performance work although he had his problems with Linus philosophy.

Let's keep our fingers crossed that he resumes on linux development as his improvements or comments were really worth it  :Smile: 

Rei

----------

## AaronPPC

It works well.  Take a look at this thread.  The zen guys have adopted it.

----------

## albright

so after you patch the kernel, then what. Does the

BFS just replace the CFQ?

I - probably out of ignorance - expected some new

options in my kernel config but don't see any.

----------

## Naib

 *albright wrote:*   

> so after you patch the kernel, then what. Does the
> 
> BFS just replace the CFQ?
> 
> I - probably out of ignorance - expected some new
> ...

 

it replaces it

The fact there is no choice is what kicked off the shitstorm over such patches

these schedulars are no good for high CPU count but great for desktop/low (<1000 or something), so the easiest thing would be a Kconfig option but the kernel dev's don't want to provide an option for other schedulars

----------

## albright

 *Quote:*   

> The fact there is no choice is what kicked off the shitstorm over such patches 
> 
>  these schedulars are no good for high CPU count but great for desktop/low (<1000 or something), so the easiest thing would be a Kconfig option but the kernel dev's don't want to provide an option for other schedulars

 

thanks for that - I just want to try out the scheduler not

"enjoy" dev politics!  :Smile: 

----------

## cheater1034

*cough* the zen kernel adds a kconfig option to select between cfs and bfs, it also lets you pick autoiso for X if you choose bfs,  :Wink: , also need to mention we have it in 2.6.30-zen and 2.6.31-zen (git only)

----------

## ToeiRei

there is quite some buzz now on the kernel mailing list about bfs as it seems that they're ripping it apart...

For us here we could do some simple benchmarking with a kernel compile if we'd decide on a .config and some basic makeopts, we could gain some results to form our opinion instead of just stating that it's cool/crap *)

*) This wasn't intended to rate the scheduler.

Rei

----------

## cheater1034

 *ToeiRei wrote:*   

> there is quite some buzz now on the kernel mailing list about bfs as it seems that they're ripping it apart...
> 
> For us here we could do some simple benchmarking with a kernel compile if we'd decide on a .config and some basic makeopts, we could gain some results to form our opinion instead of just stating that it's cool/crap *)
> 
> *) This wasn't intended to rate the scheduler.
> ...

 

Apparently the tests that have been run and posted on the mailing lists are not on standard desktop systems, not doing desktop-related tests (16+ cores, etc)

----------

## peter4

Hi, I have a silly question. I've never got around to using this 'patch' thing. I figured out how to apply it, but then it asks me:

```
patching file kernel/sched.c

Reversed (or previously applied) patch detected!  Assume -R? [n]

```

What that this mean?  :Smile: 

----------

## i92guboj

 *peter4 wrote:*   

> Hi, I have a silly question. I've never got around to using this 'patch' thing. I figured out how to apply it, but then it asks me:
> 
> ```
> patching file kernel/sched.c
> 
> ...

 

It means that the patch wasn't designed for the kernel version that you are trying to patch. Patches change specific sections of the code. If a part of the code that is affected by the patch has changed between two versions, then the patch becomes incompatible with the new version. The rejects are sometimes simple/trivial to fix, sometimes they can be ignored, sometimes it would take real knowledge about the internals of the code to fix them.

So, either use the right kernel version of wait until Con Kolivas releases an update for the patch.

----------

## peter4

Thanks.    :Smile: 

----------

## peter4

Ok, I patched the kernel and ran some kernel compilation tests. Each test was done right after a clean boot, and make clean was ran before reboot, so the conditions were more or less the same for each compile. My system is Core 2 Duo E7400 (2,80 GHz), Gigabyte MB with intel P45 chipset, 4GB RAM.

```
BFS -j2:

real    3m19.166s

user    5m9.476s

sys     0m47.521s

BFS -j3:

real    3m9.170s

user    5m10.748s

sys     0m48.186s

CFS -j2:

real    3m38.258s

user    5m6.833s

sys     0m47.251s

CFS -j3:

real    3m18.770s

user    5m8.381s

sys     0m47.748s

```

So in contrast to what Con says, the best result was achieved with -j3 with his patches.

I'll try compiling something bigger later and see what I get.

My subjective feeling is that everything really runs more smoothly now, especially on my somewhat lower shelf notebook. But it might as well be a kind of placebo  :Wink: 

Other than that, some bugs start to creep out here and there. Xorg wouldn't quit once when I tried to reboot, leading to RC scripts being unable to remount / read-only. On my laptop (samsung r60plus) when rebooting, the system stalls just before it would normally reboot (even after the *Lock diodes blink) and stay frozen until I press a key - that's very weird. On the laptop Xorg becomes unstable after suspend/resume. However, what suprised me,  I noticed that suspend/resume itself works better with these patches. With regular kernel, after resuming from suspend-to-disk half the system would be stashed in swap (maybe it's a bug and I should report it?), making everything very jerky for a few minutes. With these patches everything is back to RAM after resuming. (EDIT: it got fixed only on the laptop, on my dektop I still get ~300MB in swap. weird.)

----------

## albright

this is probably a bit off topic but anyway ...

I downloaded the zen kernel with this

```
git clone git://zen-sources.org/zen/zen.git linux-2.6-zen
```

But when I try to run make menuconfig I get errors, like this:

```
  HOSTLD  scripts/kconfig/mconf

collect2: ld terminated with signal 11 [Segmentation fault]

/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `scripts/kconfig/mconf.o' is incompatible with i386 output
```

This is an intel dual core (thinkpad x300), with x86 architecture 

(CHOST="i686-pc-linux-gnu")[/code]

Why would this be happening? TIA,

----------

## cheater1034

 *albright wrote:*   

> this is probably a bit off topic but anyway ...
> 
> I downloaded the zen kernel with this
> 
> ```
> ...

 

Please put stuff like this in the zen thread, but to answer your question: hardware failure? bad compiler?

----------

## energyman76b

 *Naib wrote:*   

>  *albright wrote:*   so after you patch the kernel, then what. Does the
> 
> BFS just replace the CFQ?
> 
> I - probably out of ignorance - expected some new
> ...

 

initial testing shows: they aren't great.

Hmmm....

----------

## energyman76b

 *cheater1034 wrote:*   

>  *ToeiRei wrote:*   there is quite some buzz now on the kernel mailing list about bfs as it seems that they're ripping it apart...
> 
> For us here we could do some simple benchmarking with a kernel compile if we'd decide on a .config and some basic makeopts, we could gain some results to form our opinion instead of just stating that it's cool/crap *)
> 
> *) This wasn't intended to rate the scheduler.
> ...

 

4 cores are pretty standard ....

----------

## AaronPPC

Until 16 cores are standard.    :Very Happy: 

----------

## ToeiRei

I guess we should not ignore that there are machines like an i7 getting more and more attention...

Rei

----------

## energyman76b

Istanbul is out, 6 cores. Magny Courts comes soon, 12 cores.

And AMD does not rule out desktop versions of the two ....

----------

## VValdo

FWIW, Android hacker Cyanogen has compiled bfs into his custom ROM and here are some of his recent tweets:

 *Quote:*   

> ok, some initial testing and bfs is really screaming! like, really really screaming.

 

 *Quote:*   

> Just want to say it again... wow.

 

 *Quote:*   

>  I think it can be made even better too, but there is almost no need. BFS + Android = sexytime

 

Should be up tomorrow (look here) for anyone using a G1 or Dream Android phone...

W

----------

## shazeal

I patched the Gentoo 2.6.30-r6 kernel with BFS 209 on my x86_64 work machine (Quad Core Intel). Whole system seems alot more responsive and less prone to "hic-ups" due to background I/O. I permanently run a VMWare machine using XP for video conferencing and that also seems alot more responsive.

No crashes or other bugs so far.  I run the BFQ I/O scheduler with it as well, have been using BFQ for a long time now. BFQ was a nice improvement, but BFS is a really big improvement  :Very Happy: 

----------

## VValdo

To follow up, the mod/patches for Android are in.  All the responses to BFS are pretty amazing...

----------

## energyman76b

so this scheduler is good for Intel up to quad core without htt and small single core cpus from arm and mips.

Bad thing even my mp3-player has a dual core arm....

----------

## gringo

 *Quote:*   

> Bad thing even my mp3-player has a dual core arm....

 

i have to agree, maybe there are some cases where it is better, but in a world where all is moving to multicore this really looks like a brainfscked scheduler  :Razz: 

cheers

----------

## furanku

For the sake of completeness: Phoronix has done some benchmarks of the BFS scheduler. Whatever you think of these benchmarks, it shows in the "Apache Static Page Serving" (p. 3) measurements, that the standard scheduler isn't optimal in all situations. It isn't just a matter of "felt responsiveness".

As schedulers are always a compromise it might be worth looking into the details which gave BFS a 65% boost in performance in that case. Maybe it's something special which can't be generalized, maybe BFS shows a general weakness of the standard scheduler in some situations and the kernel developer learn from that und improve the "overall" performance of the standard scheduler.

I still think that it's good to have just one scheduler in the kernel. If you really want you still can apply external patches.

----------

## pdw_hu

I've only one question: for SSDs I'd guess still No-op wins right? No point in choosing else, afaik.

----------

## albright

 *Quote:*   

>  Report this post   Reply with quote 
> 
>   I've only one question: for SSDs I'd guess still No-op wins right?

 

BFS is not a disk scheduler (are you thinking of BFQ?)

----------

## Apetrini

For me BFS is good. With patch 220 my glxgears gains +10%.

----------

## gimpel

I would have to boot back into vanilla 2.6.31 to really verify this, but I can't remember playing fullscreen flash videos on amd64 in a somewhat acceptable fashion ever, until I booted with this BFS. Still a bit skippy, but at least I can start counting frames per second, not per minute now.

Athlon64 X2 5600+ it is here.

First time for ages I applied a patch up on vanilla. Nice one. Good to see Con back.

Regarding the Phoronix threaded I/O tests, I'd be interested in what I/O sched they're using. I use CFQ on the system disk with ext3, and deadline on the BTRFS data array.

----------

## haarp

Just tried BFS. It seems more responsive, but I can't say how much of that is placebo. I'll continue to test it.

 *albright wrote:*   

>  *Quote:*    Report this post   Reply with quote 
> 
>   I've only one question: for SSDs I'd guess still No-op wins right? 
> 
> BFS is not a disk scheduler (are you thinking of BFQ?)

 

After reading this, I started to wonder about disk schedulers in general

Afaik, the CPU scheduler is responsible for allocating CPUs and CPU time to the processes. In case of BFS, while trying not to starve interactive processes that sleep most of the time. I think I got this right so far.

So, a disk scheduler does essentially the same for IO. So why the hell does every interactive task always freeze when there is heavy IO going on my system disk? Shouldn't it be the job of the disk scheduler to serve every task, not only those that need the most IO? Even when ionicing the heavy tasks, it will still sometimes become unresponsive.

I am aware that disk scheduling is probably harder, because one has to account for random access time of spinning media and far lower throughput than, say, L1/2/3 cache or RAM. But the problem remains - interactive tasks often starve.

Wouldn't it be a good idea to make some kind of BFS for disks? A scheduler optimized for the desktop environment that works really well with normal harddrives (and SSDs) and tries to stay as interactive as possible? (Yes, I know that you can't just take BFS' algorithm and put it into a disk scheduler....)

----------

## Ivan The Viking

In pf sources, there's an alternate scheduler, BFQ, that I've been trying out that doesn't seem to bog as badly as the default CFQ I've had forever.

http://algo.ing.unimo.it/people/paolo/disk_sched/

Seems it's in the Zen Kernel also.  I recommend a quick glance if you're fed up with CFQ's performance.

----------

## pross

BFQ is also part of my overlay: here

----------

## hook

Any experience with running BFS on a (dual core) laptop?

After years of vanilla-, I'm now pretty happy (again for years) with gentoo-sources, and wonder if BFS is a reason to switch again (to zen- or ck-) or even manually patch kernel.

----------

## kernelOfTruth

 *hook wrote:*   

> Any experience with running BFS on a (dual core) laptop?
> 
> After years of vanilla-, I'm now pretty happy (again for years) with gentoo-sources, and wonder if BFS is a reason to switch again (to zen- or ck-) or even manually patch kernel.

 

when you're attempting to patch your kernel you can compare the new CFS with autogroup to BFS (as base use 2.6.37):

1)  [GIT PULL] scheduler changes for v2.6.38  

2)  [GIT PULL] scheduler fixes 

that way you'll see that Con has pushed the mainline kernel in the right direction  :Wink: 

----------

## hook

 *kernelOfTruth wrote:*   

> 
> 
> when you're attempting to patch your kernel you can compare the new CFS with autogroup to BFS (as base use 2.6.37):
> 
> [...]
> ...

 

You're saying since 2.6.37 basically something similar to BFS has been integrated into CFS of the vanilla kernel tree?

----------

## kernelOfTruth

 *hook wrote:*   

>  *kernelOfTruth wrote:*   
> 
> when you're attempting to patch your kernel you can compare the new CFS with autogroup to BFS (as base use 2.6.37):
> 
> [...]
> ...

 

hm ?   :Surprised: 

not really - I should have emphasized that I mean the "performance" or keeping interactivity (gui reponsiveness) under heavy load

at least the great responsiveness can be compared but the concept behind it is quite different ...

you can read about BFS more in  Con's Blog 

 *Con Kolivas wrote:*   

> 
> 
> Queuing theory and BFS
> 
> I had pointed out to me on IRC by Damentz the queuing theory video that was linked by a slashdot article.
> ...

 

----------

## hook

 *kernelOfTruth wrote:*   

>  *hook wrote:*    *kernelOfTruth wrote:*   
> 
> when you're attempting to patch your kernel you can compare the new CFS with autogroup to BFS (as base use 2.6.37):
> 
> [...]
> ...

 

That's what I meant, yeah. Similar result, but with a different (probably more complex then BFS) concept.

 *Quote:*   

> 
> 
> you can read about BFS more in  Con's Blog 
> 
>  *Con Kolivas wrote:*   
> ...

 

Oooooh, nice, thanks  :Very Happy: 

Hmmm, the single queue does sound more sensible, but I dunno. I guess I'll wait and see how CFS in 2.6.37 improves and then decide.

----------

## hook

 *kernelOfTruth wrote:*   

> 
> 
> hm ?  
> 
> not really - I should have emphasized that I mean the "performance" or keeping interactivity (gui reponsiveness) under heavy load
> ...

 

That's what I meant, yeah. Similar result, but with a different (probably more complex then BFS) concept.

 *Quote:*   

> 
> 
> you can read about BFS more in  Con's Blog 
> 
>  *Con Kolivas wrote:*   
> ...

 

Oooooh, nice, thanks  :Very Happy: 

Hmmm, the single queue does sound more sensible, but I dunno. I guess I'll wait and see how CFS in 2.6.37 improves and then decide.

----------

