Tuesday, 29 March 2011

2.6.38-ck2, BFS 0.370

EDIT EDIT EDIT: This patch causes bizarre regressions and has been backed out. Consider 2.6.38-ck1 and BFS0.363 the stable releases, SORRY!

After more testing and cleaning up of the patch posted here earlier (test2), I've put it together as a new BFS release with almost trivial changes since that test2 patch. The changes are cosmetic only apart from a removal of the warning which is hit occasionally and is now harmless on BFS.

Just to reiterate, unless you are on an SMP machine (2 or more threads or cores) AND are using a scaling CPU frequency governor (e.g. ondemand), then there will be no significant performance advantage to upgrading to BFS 370 or ck2. For those with that combination, what you can expect to see is an increase in throughput with lightly loaded machines (single threaded apps most affected) and likely an increase in battery life. Overall latency is unlikely to be affected keeping interactivity relatively the same but responsiveness should also increase. If you are unsure of the difference, read this summary I wrote for interbench:

When the kernel mirrors sync up, ck2 will be found here:
It applies with some minor offsets to so you can safely apply it to that kernel if you like.

BFS is available here:

And Ubuntu packages of and which have the new BFS are now available here:
Ubuntu Packages

EDIT: People keep asking me why I've "optimised" only for SMP and ondemand. This is not the case at all. This patch addresses a performance regression that only affects that combination.



  1. I diff the bfs-363 and bfs-370 for 2.6.38. I only notice 2 place are different with bfs363-test2.patch in sched_bfs.c.

    @@ -1900,7 +1983,7 @@
    return this_rq()->rq_running +
    (queued_notrunning() + nr_uninterruptible()) /
    - (1 + num_online_cpus());
    + (1 + grq.noc);
    //bfs370 (grq.noc ? : 1);

    * Print scheduling while atomic bug:
    @@ -2931,10 +3086,12 @@
    schedstat_inc(rq, sched_goidle);
    } else {
    - next = earliest_deadline_task(rq, idle);
    - prefetch(next);
    - prefetch_stack(next);
    - clear_cpuidle_map(cpu);
    + next = rq->edt(rq, idle);
    + if (likely(next != idle)) {
    //bfs370 if (likely(next->prio != PRIO_LIMIT)) {
    + prefetch(next);
    + prefetch_stack(next);
    + clear_cpuidle_map(cpu);
    + }

    Can I modify them in bfs363-test2.patch and use on 2.6.37? I have tried to pack ck kernel with bfs363-test2.patch on openSUSE build service. here is the repository...

  2. Yes, that's fine. There was also the removal of some debugging stuff.

    - WARN_ON(rq != this_rq());
    - BUG_ON(p == current);
    - lockdep_assert_held(&grq.lock);

  3. I patched linux- with bfs363-test2.patch over ck1-patchset.
    I had a jerking when playing the old blockout2 game (gl-app) on enabled window effects kde-4.6.1 gentoo~ . So I changed back to bfs363. It feels better on core2-64bit.

  4. Thank you SO much for giving feedback. It's extremely hard to make a comprehensive judgement unless I get feedback, but hardly anyone reported back on the test2 patch. I'm wondering if this change is a dud after all.

  5. Since linux-2.6.38 vanilla made advancements in regard of latency and performance over (the 2.6.37 I omitted) I have little (but I have) feelings about better BFS. I would like to configure some latency/performace measurement, because just feelings are poorly getting me information.

    Con Kolivas would you please blog about some easy to configure tools?

  6. I just started to test it and then heard the bad news... I noticed some issue, but I haven't repeated them again.
    1. the cpu clock seems keeping on low a while when I unplug adapter and plug it back. (power saving policy changed)
    2. sometimes playing video is not smooth
    3. firefox4 running many flash will be slow, but 363 seems more better.
    except these above, others are good.
    I 'm not sure these issues are really. Need more time to test...and tools like Ralph said. :-P