Saturday 24 March 2012

3.3.0-ck1

New -ck version for the latest mainline linux kernel, 3.3.0:


3.3-ck1

Changes since 3.2.0-ck1:

New BFS version 0.420 AKA smoking as discussed here:
bfs-420-aka-smoking-for-linux-33

Includes one build bugfix for UP compared to that first release candidate.

Other changes:
These patches have been dropped:
-mm-background_scan.patch
-mm-lru_cache_add_lru_tail-2.patch


The Virtual Memory subsystem has changed so much it's hard to know if these patches do what they originally intended to do, nor if they are helpful any more. In the absence of being able to test their validity, it seems safer to just drop them.

The rest of the patchset is just a resync.

Enjoy!
お楽しみ下さい

91 comments:

  1. お楽しみ下さい = Please enjoy!

    googletranslate power :)

    ReplyDelete
  2. Thanks, CK. I wanted to see if a high number of replicates would eventually show a separation in the bfs v0.416 vs bfs v0.420 make test for the quad core chip. It didn't even going out to n=72. Nor did it on a dual HT chip. Only the dual quad HT machine seemed to give a statistically significant difference between the two bfs versions.

    ANOVA-Three Machines

    The 'make benchmark' is compiling the linux 3.3.0 via 'make -jx bzImage' and timing the result. The "x" corresponds to the number of cores on the box. In this case, n=x for the quad and dual core chip (HT) and n=x for the dual quad (HT). This is done via a bash script.

    ReplyDelete
  3. Thanks for the ck patch for 3.3. It's working very nicely for me. By the way, would it be possible for you to change the timer frequency patch to allow a numeric value to be set in the kernel config file instead of having to chose from a list of preselected values? I'm curious as to whether or not 30Hz could give better throughput on a server without making it unresponsive and if 500Hz or 700Hz could could improve throughput on the desktop without any noticeable loss of responsiveness. It could also allow people that want to tweak their system to the max for responsiveness to try 1050Hz or 1100Hz.

    ReplyDelete
  4. Thanks Tux. In principle it's a reasonable idea however lots of code in the kernel breaks with values below 100 (divide by zero errors etc.), and to be perfectly honest no one would be able to distinguish anything between 1000, 1050 or 1100 either perceptibly or with any benchmarks. Only coarser increments make sense I'm afraid. Maybe 500 as extra.

    ReplyDelete
  5. Heh. Mike Galbraith, as usual: https://lkml.org/lkml/2012/3/25/38
    "For normal desktop use, I don't see any real difference with BFS vs CFS"

    ReplyDelete
    Replies
    1. Oh boy... I smell a flamewar.

      Delete
    2. If he were to try compiling something or doing video encoding in the background while playing a game like Unreal Tournament 2004 or Team Fortress 2, he would have noticed a big difference. When I do this with CFS, I can really notice it in the game. With BFS, I have to quit the game every once in a while to check if it finished because I can't tell otherwise. Perhaps this isn't "normal desktop use." I wonder if he also set all the right kernel config options (no tickless, 1000Hz, no cgroups, full preemption).

      Delete
    3. Be aware that Mike was responsible for the "interactive tuning" of CFS. This may help you understand his comment. There will be no flamewar as I never respond to him. There's a special game people play unwittingly on mailing lists called "If I get the last word in and the other person stops responding that means I won". I stopped playing it years ago.

      Delete
    4. I agre that Mike's comment is flawed. Nobody cares about top loading snapshot at any given moment, we are interested in a larger window averages. Also reporting the real time for one program and conviniently hiding the share that the massive_intr was getting is a shell game.

      However, I see that the heterogenopus loading is never tested with only make -j. Show me make -j competting with x264 encoding and I will be convinced.

      Delete
    5. Since people are querying the fairness aspect of BFS, I felt obliged to post a rebuttal, more for the users than Mike.
      http://lkml.org/lkml/2012/3/26/482

      Delete
  6. 0.420 "smoking", I like that version! :-)

    ReplyDelete
  7. Regarding fairness: Once the United Nations will declare human rights to computer programs then Con Kolivas ends up on some watch list ...

    If we had the scheduler plugin infrastructure in place, we could dry-run the other scheduler in paralel to see what other decisions it would make at the same point ...

    A question to the other mm ck1 patches: If you have transparent huge pages enabled there is a kind of defrag background process going on. If you then minimize swap behavior wouldn't this harm? Also idling these tasks too much, could this provoke a race condition when using virtualbox for example?

    Ralph Ulrich

    ReplyDelete
  8. CK - I have been running a `nice -19 make -j16 bzImage` looped on that dual quad system for a while now logging the output of `top -b` to a text file. I cannot locate any PR values >41 in the log and thus cannot reproduce that unusual bug. I have given up :)

    $ wc -l log.txt
    8826530 log.txt

    $ awk '{ print $3 }' log.txt | sed -e '/RT/d' -e '/total/d' -e '/PR/d' -e '/sy/d' | sort -rn
    41
    41
    41
    ...

    ReplyDelete
    Replies
    1. Thanks. I'm pretty sure it has been fixed.

      Delete
  9. one thing I noticed is that it does this all the time

    1183 ? S 0:00 \_ [xfsaild/sda10]
    2168 ? S 0:06 \_ [cifsd]
    2243 ? S 0:01 \_ [flush-8:0]
    27126 ? S 21114581:29 \_ [kworker/1:0]
    461 ? S 0:00 \_ [kworker/0:2]
    17004 ? S 0:00 \_ [kworker/1:2]
    17501 ? S 0:00 \_ [kworker/0:1]

    seems when there is something that bogs the kernel down some processes do this. it has been doing it for a few versions now.

    ReplyDelete
    Replies
    1. No, there is something wrong with the accounting of time as seen by some userspace applications. I simply haven't spent time tracking down what causes it as I don't think there is actually a problem with behaviour, only the reporting.

      Delete
  10. I've been compiling kernel since version 2.3.32 always with bfs, 1000hz, removing swap and usng liquorix .config, and, this BFS version with kernel 3.3 I think it's the best I've ever seen, faster, no lags in any software I run, faster boot time, also with kernel 3.3 came with some drivers fixs and some tweaks on networking, that you can feel, so best version till now...
    I tested without BFS (but using a lower dirt ratio, 1000hz, prempt desktop), you can really feel the difference using BFS or CFS, probabaly this last fixes from BFS helped a lot, in performance therms, nice work!

    ReplyDelete
  11. Hi, CK, is your bfs support ulatencyd?
    can i use bfs with ulatencyd?

    when i use bfs, the ulatencyd look like not working.
    how can i configurare it work together?

    ReplyDelete
  12. This might help: https://bbs.archlinux.org/viewtopic.php?id=122946

    ReplyDelete
  13. BFS does not support CPU cgroups. (The point is that it doesn't need them.) ulatencyd is using cgroups to control CPU bandwidth dynamically. So it can't work with BFS.

    ReplyDelete
  14. http://sourceforge.net/projects/scriptkernel/

    recomended test

    ReplyDelete
  15. Hi CK,

    Is there any profiling reports available as im interested in tinkering, and would love to see the hard hitting and freq areas?

    Thankyou
    Mike Brown

    ReplyDelete
    Replies
    1. I don't fully understand task_times() but can we not simplify the math and pos remove the branch?

      Delete
  16. Hi CK & BFS-Community!

    Has someone of you already tried to review / test the new RIFS V2 (Rotary Interactivity Favor Scheduler) from Mou Chen? (See http://marc.info/?l=linux-kernel&m=133675617620526&w=2 for the announcement + patch)

    Although the patch even contains many unneeded things that irritate -- it looks to me like a somehow "enhanced" version based on or including much of the most recent CK patchset. Mou Chen has written he wanted to clean up his patch (what didn't happen so far?). I've uploaded the patch after cleaning up the trivial things: http://pastebin.com/XfZ0A4mi

    Best regards,
    Manuel Krause

    ReplyDelete
  17. This is from the comments thread @ Phoronix:

    "It's true that it handles interactivity under heavy load better than bfs, but almost every cpu intensive task seems to be slower with the patch. i'm going to this patch again tomorrow."

    "Well, that is the price you pay for interactivity or low latency.
    Seems like the main problem is that io kthreads aren't preemptible with the kernel most desktops use. Please Ubuntu, Debian, Mint, Fedora, and Suse, make the preempt kernel default.
    If someone is running a server then either offer a server spin, or the less preemptive kernel for them in the repos.
    Without these more strongly preemptive kernels schedulers just don't matter very much. Sure, you'll see some differences, but you'll see more differences between them if you change kernels. This is why I think Android didn't go with bfs(or some other scheduler than cds)."

    ReplyDelete
  18. Con, are you aware there is a person named Hillf Danton posting patches to BFS 4.20 on the LKML? I seem to remember he comes from an Android background but i may be wrong.

    ReplyDelete
    Replies
    1. I'm completely swamped by real life and not remotely paying attention to LKML and he hasn't cc'ed me.

      Delete
    2. https://lkml.org/lkml/2012/5/18/178 - Re: BFS 420: fix ttwu stat
      http://www.kernelhub.org/?msg=68547&p=2 - BFS 420: nuke the sticky bits
      http://www.kernelhub.org/?msg=71247&p=2 - BFS 420: cleanup in tick handling
      http://www.kernelhub.org/?msg=69901&p=2 - BFS 420: cleanup try_preempt

      http://www.kernelhub.org/?msg=67745&p=2 [1/3] BFS 420: correct getting rr interval
      http://www.kernelhub.org/?msg=67747&p=2 [2/3] BFS 420: compact enqueue_task
      http://www.kernelhub.org/?msg=67748&p=2 [3/3] BFS 420: cleanup the default root domain

      (Some of the threads were inaccessible via lkml)

      Mike Brown

      Delete
    3. Very interesting, I wonder what Con thinks about them.

      Delete
    4. With real life commitments, I don't even have time to review them right now.

      Delete
    5. I'd like to see an "unofficially mantained" BFS (perhaps including Danton's patches) for those of us who want/need to stay up-to-date with recent kernel versions... both BFS and BFQ are mantained by one or a couple of persons at max.

      Delete
    6. i dont see any value.. bfs is a component/algorithm. If there is anything relavent to its goal(s) then it would be unproductive having that information elsewhere.

      If dantons patches are corrections/bugfixes. its important to give them to everyone. If they are policy changes, then we are no longer 'bfs'.

      if you are willing to review the patches and/or bfs code and specifically suggest bugfixes then im more than positive ck will acknowledge any improvements.

      Mike Brown

      Delete
  19. Keep up the good work and do what you love !
    Thanks for the patches !

    ReplyDelete
  20. save everyone a few minutes of time if they want to test the unofficial patches

    wget https://lkml.org/lkml/diff/2012/5/25/233/1 -O bfs_patch_1.patch
    wget https://lkml.org/lkml/diff/2012/5/25/235/1 -O bfs_patch_2.patch
    wget https://lkml.org/lkml/diff/2012/5/25/217/1 -O bfs_patch_3.patch
    wget https://lkml.org/lkml/diff/2012/5/25/231/1 -O bfs_patch_4.patch
    wget https://lkml.org/lkml/diff/2012/5/25/312/1 -O bfs_patch_5.patch
    wget https://lkml.org/lkml/diff/2012/5/25/200/1 -O bfs_patch_6.patch
    wget https://lkml.org/lkml/diff/2012/5/22/154/1 -O bfs_patch_7.patch

    ReplyDelete
  21. Very,very thank you, I tried by copying from kde-knode but got a lot of bad and missing white spaces ...

    Do you think these are all Hillf patches?

    I am very curious if my linx-3.3.7-bfs420patched kernel will run better than before: I had a slowing down after some hours - not much though.

    Ralph Ulrich, Germany

    ReplyDelete
  22. No, no
    :(
    These seven patches dont work: First screen is a stacktrace, something like

    init-workqueue
    cpu-isolating
    Bfs exciting

    Ralph Ulrich, Germany

    ReplyDelete
  23. Hillf Danton posted 22 patches to lkml in total (as of today). Not very easy to fetch. Some of them seem to me to be simple cleanups. But I don't have enough knowledge to determine if they're useful or complete or which ones are needed at all or should be excluded.
    Would be glad if someone 'who knows' posted some hints about it. ^^

    Manuel Krause

    ReplyDelete
  24. Hi Con
    I have find a method to let the earliest deadline task choosing become O(1).(I have spent some time to post this because I m using Tor to crawl out from GFW. The chinese gov has blocked us from Blogspot)

    I 'll send you a copy of this by email.

    We can use 40 list_head instead of the single list for time sharing scheduling policy. Then for task selection we will select the task from these 40 list_head(actually is less than 40, just decide by next_sched_bit), then make a comparsion of these tasks(actually in the worse case we just need to do 40 times of comparsion) and pick the lowest task. If a task wake, it would be the first node of (queue + p->static_prio). If a task run out of its timeslice, it will become the last node of(queue + p->static_prio). This is a concept of BFS deadline presort algorithm and the time complexity is O(1)

    Why we just need to compare 40 times is because the value of PRIO_RANGE is 40.

    For example , in the following case: 0 1 0 0 1 1 0 0 0 0 0 0 (bitmap)

    We just need to compare 3 times. Because PRIO_RANGE is a constant, the algorithm is O(1). We just need to compare the first task of q1, q4 and q5.

    Chen

    ReplyDelete
    Replies
    1. btw instead of tor you can also try freegate, it's a lot faster: www.dit-inc.us/freegate

      Delete
    2. Freegate doesn't work well. :-(

      Delete
    3. Or perhaps ultrasurf.us

      Delete
  25. Hillf Danton just has published a summury patch of his previous 21 patches which he calls bfs-421

    I wonder how this is received by Con ...

    Ralph Ulrich
    from Hamburg

    ReplyDelete
    Replies
    1. At least he did this:
      - printk(KERN_INFO "BFS CPU scheduler v0.420 by Con Kolivas.\n");
      + printk(KERN_INFO "BFS v0.421 derived from v0.420 by Con Kolivas\n");
      ;-)

      Doesn't work for me for now anyways. I suspect it has something to do with my single CPU, single core PIII CPU. Bootup hangs after CPU initialisation.

      Manuel Krause

      Delete
  26. But this summury patch terribly fails to patch
    linux-3.3.7

    Applying patch patches/zfeatures/patch_BFS_420_a_tiny_step_forward.patch
    patching file include/linux/sched.h
    patching file kernel/sched/bfs.c
    Hunk #4 succeeded at 716 with fuzz 2.
    Hunk #5 succeeded at 1074 with fuzz 2.
    Hunk #7 succeeded at 1427 with fuzz 1.
    Hunk #8 FAILED at 1444.
    Hunk #10 FAILED at 1488.
    Hunk #11 FAILED at 1537.
    Hunk #12 succeeded at 1582 with fuzz 1.
    Hunk #13 FAILED at 1598.
    Hunk #15 FAILED at 1630.
    Hunk #16 FAILED at 1725.
    Hunk #17 FAILED at 1777.
    Hunk #18 FAILED at 2770.
    Hunk #19 succeeded at 2814 with fuzz 2.
    Hunk #20 FAILED at 2826.
    Hunk #21 FAILED at 3069.
    Hunk #24 succeeded at 4573 with fuzz 1.
    Hunk #25 FAILED at 4829.
    Hunk #26 FAILED at 4956.
    Hunk #27 succeeded at 5122 with fuzz 1.

    Ralph Ulrich

    ReplyDelete
    Replies
    1. Hi Ralph, where did you get the patch from? If you took it from lkml everyhing patches fine on top of kernel 3.3.7 & BFS_420.

      Manuel Krause

      Delete
    2. He had already hang himself up because of a list a of bug,that is.:D

      Actually he doesn't not really want to help BFS to improve.He just wants himself to become famous.

      Delete
    3. You did insert whitespaces into the copied & pasted text document, did you?! ;-) MK

      Delete
  27. Excuse my last message: Hillf D. summary diff patches. It was my bloody knode program which I use to watch the kernel mailing list. How to get that patch cleanly - I just wonder.

    Ralph Ulrich
    Hamburg

    ReplyDelete
    Replies
    1. http://marc.info/?l=linux-kernel&m=133838729201059&w=2
      copy & paste
      insert one whitespace to each empty newline
      ready for patching

      Manuel

      Delete
    2. Doesnt work, because copy-paste adds up a thousends of blanks and tabs into the copied text.
      Saving the html page also doesnt work, because there are lots of html inserted characters.
      Ralph Ulrich

      Delete
  28. After hand editing a japanese in the bfs-421-patch I had it working. But compile fails for linux-3.3.7:
    kernel/sched/bfs.c: In function ‘try_preempt’:
    *kernel/sched/bfs.c:1450:2: error: incompatible type for argument 2 of ‘cpumask_next_and’

    ReplyDelete
  29. Then your hand editing went wrong. Compiling worked here. Also I don't have a ‘cpumask_next_and’ in bfs.c
    Please, check carefully! Manuel

    ReplyDelete
  30. The danton patches remove the priority feature from bfs, with the possibility of a few bug fixes, Id recommend holding off on them for now.

    ReplyDelete
    Replies
    1. As the scheduler runs often, really!
      We need it error free. Now that there are maintained realtime kernels in every distribution easy to install, better a less capable BFS for the majority of people!

      By the way, to me - not a developer - these H.D. patches just look like easy bug findings:
      ---
      -       rq = task_grq_lock(p, &flags);
      +       rq = task_grq_lock(p->parent, &flags);
      ---
      -         BUG_ON(!cpumask_test_cpu(cpu, rq->rd->span));
      +         BUG_ON(cpumask_test_cpu(cpu, rq->rd->span));
      ---
      But I admit to not know what BUG_ON does ...

      Delete
    2. ... and if a feature less BFS brings a performance boost, I also would prefer to get rid of that feature! Wasn't this the philosophy of BFS in the first plase: Keep it simple and just going for the most of users?
      Ralph Ulrich

      Delete
    3. Alas the first does nothing since the first argument is there for consistency only and is optimised out and the 2nd part is not correct.

      Delete
    4. I don't want a "less capable BFS" just for the majority of people. Whatever you intended to say... Con Kolivas would make the best BFS anyways. :-)

      Manuel Krause

      Delete
    5. Manuel, then we need a fork: Out there - mainline CFS - is highly configurable. And must be configured (as distributions do hopefully). We need a not-need-to-know Scheduler for the most people.

      Delete
    6. ck said: "Alas the first does nothing since the first argument is there for consistency only and is optimised"
      The real bug is documentation then:
      + /* p->parent seems right, but we don't need p anyway */
      Sure, documentation was not needed as long as there was a single developer

      Delete
  31. I've had a look over the combined patches and unfortunately I have to say there's little to nothing in it that I can use in the next real BFS. Unless he submits them all to me one by one I can't really comment on them, but I doubt I can use any of it as is at the moment as quite a few things are subtly broken in there.

    ReplyDelete
    Replies
    1. Should I send the previous approx. 23 single patches to your mail addy? ;-)
      I've collected them all. :-)
      OMG. ~thunder~

      Manuel Krause

      Delete
    2. The single patches from Hillf Danton have an introduction at the top at least. The summary is just for Emmanuel Benisty and comes out without desciption en detail. ^^

      Manuel Krause

      Delete
  32. No, not wrong editig, Emmanuel Benisty on LKML showed the same compile error! If compilation worked for you, could you just inspect a diff of your .config with Emmanuels?

    Ralph Ulrich

    ReplyDelete
    Replies
    1. Ähem... How deeply do I need to go into that .config diff??? Please advise me: I get 326 diffs. And many of them are not BFS related. "WHERE should I search for WHAT?!11": That's my opinion on .config diffs generally.

      When Hillf Dantons patch fails to compile depending on .config diffs or the compiled kernel fails to pass CPU initialisation -- and hangs for me -- there's something going wrong.

      Manuel Krause

      Delete
    2. "That's my opinion on .config diffs generally."
      Yes,
      I for long advocate we need a web-service showing us the relevant pieces :(
      Ralph Ulrich

      Delete
    3. @Ralph, that's not my job.
      Where is the relevant diff? What do you assume?
      Is it:
      -# CONFIG_64BIT is not set
      -CONFIG_X86_32=y
      -# CONFIG_X86_64 is not set
      +CONFIG_64BIT=y
      +# CONFIG_X86_32 is not set
      +CONFIG_X86_64=y
      CONFIG_X86=y
      ?

      Manuel Krause

      Delete
    4. As turns out Con says below these H.D. patches dont fix anything. No need to work about that ...

      I was hot about H.D. patches, because I had observed some retarding when running my linux-3.3.x-bfs420 gentoo system for hours. Ever less performance after some hours...

      But such issues could be introduced by "tainting" proprietary software (nvidia,broadcom-wl)....
      Ralph Ulrich

      Delete
  33. Con, now would be the time a github account could help collaborating :)
    Ralph Ulrich

    ReplyDelete
    Replies
    1. I don't need github. WTH is github?
      Cons released patches always came in time. And applied and compiled.

      For now I'm still glad with openSUSE 3.3.7 + BFS_420 + mm-drop_swap_cache_aggressively.patch +BFQ.

      Manuel Krause

      Delete
    2. "drop_swap_cache_aggressively"
      Do you have TransparentHugePageTables activated, and don't you consider it's defragmentation feature needs some aggressivly space hold free, just in case you get out of free RAM space?
      Ralph Ulrich

      Delete
    3. I don't have THP & Co. enabled, as I thought it to be too time consuming for my lowest-end CPU (in nowadays' measurements). Same for mem compaction, zcache, cleancache, frontswap, o. dgl.

      I don't get out of RAM since some kernel revisions ago. (Can't say exactly.)

      Manuel Krause

      Delete
  34. I think a lot of you are missing the point. I was being polite so I guess I should be more explicit. Virtually all of the code in that patch is naive and actually wrong and breaks BFS' behaviour...

    ReplyDelete
    Replies
    1. Yes. Doesn't boot ;-) BFS 420 does. MK

      Delete
    2. But, dear Con Kolivas, you also should explain the "missed point", "naive" & "wrong" things to us -- at least to get a little more of insight.

      Manuel Krause

      Delete
    3. Yes, doesnt boot. Emmanuel Benisty just showed:
      http://ompldr.org/vZTE1eQ/IMG_20120531_200543.jpg
      But I hope Hillf Danton keeps trying,
      because I would like to have a feature poor but error free and performant working BFS. Ralph Ulrich

      Delete
  35. Sigh... I've tried to be reserved and

    He's made the hot path of the enqueue task slower by passing it more arguments and adding more compares thinking he cleaned up a rarely used function. He completely broke nice functioning at all. Preemption broke and would cause lots of unnecessary reschedules for the wrong tasks. A vast amount of cpu cache warmth effects were broken that would adversely affect throughput. He put extra code into the expensive task taking code path with schedstats that doesn't work that way on BFS from CFS. He put fixes in that fixed nothing and sometimes broke what works. He was inconsistent about removing features yet leaving parts of them behind.

    But, if you don't believe what the code does and are quite happy to think it's going to be performant, be my guest and use it for yourself.

    As much as I would like to encourage people to hack on BFS, this is not the way to go about it, and especially without even involving me. But if he wants to maintain a fork of BFS, then that's his business.

    I've been busy preparing for a work interview, so to be honest, I've had trouble caring about code for a while. I will be syncing up BFS with 3.4 once I have more time, which is not far away.

    ReplyDelete
    Replies
    1. Thanks. I'll wait for BFS for 3.4, no need for BFS forks :)

      Delete
  36. I will also wait. Good luck on the interview, I have two myself tomorrow lol

    ReplyDelete
  37. Good luck Con.
    And wait for new BFS.
    thnaks for your hard work !

    ReplyDelete
  38. If we now get 4 versions of a working Linux scheduler in place
    (con,hillf,chen,mainline)
    perhaps there is a chance to get mainline a compile time plugin infrastructure. If not this was ridiculous once more ...
    Ralph Ulrich

    ReplyDelete
    Replies
    1. Except Hilff's broken one, all of them work.

      BFS is very fair, RIFS can treat the interactive task well even with big workload. Eh..I can't say anything that is good about CFS.If you really want to get something good comment about CFS, I would say CFS can support insane configuration(***IT IS NOT NECESSARY FOR DESKTOP***)

      Chen

      Delete
    2. Cool: insanity feature rich

      /me waiting still for a fix:
      USE="bull" emerge cow
      (in case you didnt know the oldest gentoo bug)
      Ralph

      Delete
  39. Con, please check the mailbox, thanks. ;-)
    Subject: [PATCH 06/01]BFS O(1) improvement.The mail included a diff.I 'm trying it already.

    Also I want to give an advice to Hilff here. Please check that your code ***REALLY WORK*** before posting it. Posting the ***BROKEN PATCH*** means wasting the others' time and sucking your head into a dish of shit, also you will lost your credit! If you want to post something and you say that your work is better, please, paste a benchmark result. No people want their box to become a tool for experiment. Scheduler is a critical part of any kind of OS!

    Here I also want to post something that is interesting.


    * Chen wrote:

    > Totally about 17000 lines of code for RT sched, CFS sched, and MODULAR

    As I said it's 20 KLOC, you are probably looking at an older
    tree.

    At 20 KLOC, as I explained, the scheduler is one of the smaller
    kernel subsystems.

    Thanks,
    Ingo

    You must realise something from this mail. :D
    Chen

    ReplyDelete
  40. And for Hilff, please do not release something that is broken. Going into broken patchs means s**king your head into a pool of sh*t.You should post benchmarks if you want to claim that your things are better.
    Chen

    ReplyDelete
  41. Hillf thought he could grab some very easy fruits. But there are real documentation bugs in Cons code. Which didn't matter as long Con was a single "team". I hope he gets some motivation, if he reads Cons words.
    Ralph Ulrich

    ReplyDelete
  42. @ Ralph Ulrich,

    can you, please, explain more about the "slowing" you do experience? I experience it, too.

    Please, feel free to post to my email posted earlier on here. I keep contact to Hillf Damon, as he's interested in this, too.

    Manuel Krause

    ReplyDelete
  43. Hi Manuel,
    I cannot explain my slow down experience after some hours using linux-3.3-bfs. It is like a kind of resistance switching windows (kde-4.8).

    Also linux-3.4-bfs doesn't gain much. This was different with previous versions: Using linux-3.2-bfs was "feelable" better than mainline linux-3.2.

    If you are contacting to H.D. please tell him to use github. It is not feasable to guess what of his numerous patches in what special sequence need to be applied. Also there are problems with whitespace and special japanese characters (Easter Eggs in Con Kolivas code) when I tried to get H.D. patches through the web.

    Ralph Ulrich

    ReplyDelete
    Replies
    1. Hi, Ralph!
      Many thanks for answering. (I already thought you got lost.^^ :-? )

      For the slowdown experience - it's the same for me (window switching) but I also use the same GUI. KDE 4.8.3 ATM. Maybe that's the culprit. Or, just a moment, you also use firefox with more tabs open? Do you have a lag, over longer uptime, when switching from tab to another tab?! I have it.

      Regarding H.D.s patches, I already proposed him the way Mou Chen went, posting his patches to a code.google.com page. I don't know anything about github nor how to use it. But I'll let him know about your proposal.

      I never had any problems with reediting those patches and they did work well in the final stage (as of 3.3.8).

      Manuel Krause

      Delete
  44. @Manuel,
    sure there are Window Managers and other programs with flaws. But ever before linux-3.3 there was significant better behavior of the BFScheduler...

    code.google is ok, we should open a google group for discussions about schedulers there!

    Ralph Ulrich
    PS: You can find me as ralul at siduction.org

    ReplyDelete
    Replies
    1. @Ralph: I didn't like the 3.[0..2]ers.
      And the 3.4.2 did me a complete system abort when reading from shm/tmpfs.
      Best experience ever was 3.3.8 with D.H.s patches. But that did show this slowdown, too.

      Have you re-tested with kernels & BFS prior to the 3.3 series that there's really no slowdown?

      I already said, I only can see it after a longer uptime, say 12 to 48h. But it is fact.

      And it doesn't imply, that the CPU scheduler is wrong

      Manuel

      Delete
    2. Hi Manuel,

      linux-3.4.2-12queuePatches-bfs423-full-ck2
      runs now for some hours: good experience!

      We hat linux-3.2-bfs at siduction.org for some time without any complains from users. This one was a real difference to mainline!
      Now linux-3.4-bfs is good. No slowdown for some hours. But mainline scheduler has improved also. I cannot feel the difference any more. As this was the case with linux-3.2-bfs.

      I need to learn benchmarking ...
      Greetings from Hamburg, Ralph Ulrich

      Delete