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!
お楽しみ下さい
お楽しみ下さい = Please enjoy!
ReplyDeletegoogletranslate power :)
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.
ReplyDeleteANOVA-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.
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.
ReplyDeleteThanks 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.
ReplyDeleteHeh. Mike Galbraith, as usual: https://lkml.org/lkml/2012/3/25/38
ReplyDelete"For normal desktop use, I don't see any real difference with BFS vs CFS"
Oh boy... I smell a flamewar.
DeleteIf 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).
DeleteBe 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.
DeleteI 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.
DeleteHowever, 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.
Since people are querying the fairness aspect of BFS, I felt obliged to post a rebuttal, more for the users than Mike.
Deletehttp://lkml.org/lkml/2012/3/26/482
0.420 "smoking", I like that version! :-)
ReplyDeleteRegarding fairness: Once the United Nations will declare human rights to computer programs then Con Kolivas ends up on some watch list ...
ReplyDeleteIf 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
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 :)
ReplyDelete$ 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
...
Thanks. I'm pretty sure it has been fixed.
Deleteone thing I noticed is that it does this all the time
ReplyDelete1183 ? 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.
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.
DeleteI'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...
ReplyDeleteI 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!
Hi, CK, is your bfs support ulatencyd?
ReplyDeletecan i use bfs with ulatencyd?
when i use bfs, the ulatencyd look like not working.
how can i configurare it work together?
This might help: https://bbs.archlinux.org/viewtopic.php?id=122946
ReplyDeleteBFS 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.
ReplyDeletehttp://sourceforge.net/projects/scriptkernel/
ReplyDeleterecomended test
Hi CK,
ReplyDeleteIs there any profiling reports available as im interested in tinkering, and would love to see the hard hitting and freq areas?
Thankyou
Mike Brown
I don't fully understand task_times() but can we not simplify the math and pos remove the branch?
DeleteHi CK & BFS-Community!
ReplyDeleteHas 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
This is from the comments thread @ Phoronix:
ReplyDelete"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)."
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.
ReplyDeleteI'm completely swamped by real life and not remotely paying attention to LKML and he hasn't cc'ed me.
Deletehttps://lkml.org/lkml/2012/5/18/178 - Re: BFS 420: fix ttwu stat
Deletehttp://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
Very interesting, I wonder what Con thinks about them.
DeleteWith real life commitments, I don't even have time to review them right now.
DeleteI'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.
Deletei 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.
DeleteIf 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
Keep up the good work and do what you love !
ReplyDeleteThanks for the patches !
save everyone a few minutes of time if they want to test the unofficial patches
ReplyDeletewget 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
Very,very thank you, I tried by copying from kde-knode but got a lot of bad and missing white spaces ...
ReplyDeleteDo 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
No, no
ReplyDelete:(
These seven patches dont work: First screen is a stacktrace, something like
init-workqueue
cpu-isolating
Bfs exciting
Ralph Ulrich, Germany
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.
ReplyDeleteWould be glad if someone 'who knows' posted some hints about it. ^^
Manuel Krause
Hi Con
ReplyDeleteI 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
btw instead of tor you can also try freegate, it's a lot faster: www.dit-inc.us/freegate
DeleteFreegate doesn't work well. :-(
DeleteOr perhaps ultrasurf.us
DeleteHillf Danton just has published a summury patch of his previous 21 patches which he calls bfs-421
ReplyDeleteI wonder how this is received by Con ...
Ralph Ulrich
from Hamburg
At least he did this:
Delete- 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
But this summury patch terribly fails to patch
ReplyDeletelinux-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
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.
DeleteManuel Krause
He had already hang himself up because of a list a of bug,that is.:D
DeleteActually he doesn't not really want to help BFS to improve.He just wants himself to become famous.
You did insert whitespaces into the copied & pasted text document, did you?! ;-) MK
DeleteExcuse 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.
ReplyDeleteRalph Ulrich
Hamburg
http://marc.info/?l=linux-kernel&m=133838729201059&w=2
Deletecopy & paste
insert one whitespace to each empty newline
ready for patching
Manuel
Doesnt work, because copy-paste adds up a thousends of blanks and tabs into the copied text.
DeleteSaving the html page also doesnt work, because there are lots of html inserted characters.
Ralph Ulrich
After hand editing a japanese in the bfs-421-patch I had it working. But compile fails for linux-3.3.7:
ReplyDeletekernel/sched/bfs.c: In function ‘try_preempt’:
*kernel/sched/bfs.c:1450:2: error: incompatible type for argument 2 of ‘cpumask_next_and’
Then your hand editing went wrong. Compiling worked here. Also I don't have a ‘cpumask_next_and’ in bfs.c
ReplyDeletePlease, check carefully! Manuel
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.
ReplyDeleteAs the scheduler runs often, really!
DeleteWe 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 ...
... 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?
DeleteRalph Ulrich
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.
DeleteI 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. :-)
DeleteManuel Krause
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.
Deleteck said: "Alas the first does nothing since the first argument is there for consistency only and is optimised"
DeleteThe 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
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.
ReplyDeleteShould I send the previous approx. 23 single patches to your mail addy? ;-)
DeleteI've collected them all. :-)
OMG. ~thunder~
Manuel Krause
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. ^^
DeleteManuel Krause
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?
ReplyDeleteRalph Ulrich
Ä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.
DeleteWhen 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
"That's my opinion on .config diffs generally."
DeleteYes,
I for long advocate we need a web-service showing us the relevant pieces :(
Ralph Ulrich
@Ralph, that's not my job.
DeleteWhere 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
As turns out Con says below these H.D. patches dont fix anything. No need to work about that ...
DeleteI 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
Con, now would be the time a github account could help collaborating :)
ReplyDeleteRalph Ulrich
I don't need github. WTH is github?
DeleteCons 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
"drop_swap_cache_aggressively"
DeleteDo 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
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.
DeleteI don't get out of RAM since some kernel revisions ago. (Can't say exactly.)
Manuel Krause
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...
ReplyDeleteYes. Doesn't boot ;-) BFS 420 does. MK
DeleteBut, dear Con Kolivas, you also should explain the "missed point", "naive" & "wrong" things to us -- at least to get a little more of insight.
DeleteManuel Krause
Yes, doesnt boot. Emmanuel Benisty just showed:
Deletehttp://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
Sigh... I've tried to be reserved and
ReplyDeleteHe'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.
Thanks. I'll wait for BFS for 3.4, no need for BFS forks :)
DeleteI will also wait. Good luck on the interview, I have two myself tomorrow lol
ReplyDeleteGood luck Con.
ReplyDeleteAnd wait for new BFS.
thnaks for your hard work !
If we now get 4 versions of a working Linux scheduler in place
ReplyDelete(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
Except Hilff's broken one, all of them work.
DeleteBFS 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
Cool: insanity feature rich
Delete/me waiting still for a fix:
USE="bull" emerge cow
(in case you didnt know the oldest gentoo bug)
Ralph
Con, please check the mailbox, thanks. ;-)
ReplyDeleteSubject: [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
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.
ReplyDeleteChen
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.
ReplyDeleteRalph Ulrich
@ Ralph Ulrich,
ReplyDeletecan 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
Hi Manuel,
ReplyDeleteI 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
Hi, Ralph!
DeleteMany 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
@Manuel,
ReplyDeletesure 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
@Ralph: I didn't like the 3.[0..2]ers.
DeleteAnd 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
Hi Manuel,
Deletelinux-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