Announcing the release of BFS for 3.4, along with the complete -ck1 patch.
BFS alone:
3.4-sched-bfs-422.patch
Full 3.4-ck1 patches:
3.4-ck1
Alas I was unable to keep the 420 number for BFS due to a number of minor changes. I also incremented the number beyond the unofficial 421 patch put to lkml so there was no confusion. The only changes are that some trivial display accounting fixes were added, along with forcing SLUB in the config by default as other SLAB allocators crash with BFS (you should all be using SLUB anyway). The rest of the BFS changes are a resync with the new code going into linux 3.4, along with more merging of code from mainline into BFS where suitable. Note that I have adopted the mainline approach of dealing with unplugged I/O. Previously I had spent a lot of time making it work with BFS for those who remember that period of instability, so hopefully the mainline approach will work seamlessly now (since mainline ended up having the same bug but it was harder to reproduce).
3.4-ck1 is just a resync of the remainder of the patches from 3.3-ck1.
Enjoy!
お楽しみください
EDIT: If you build on SMP without enabling CPU hotplug you will need this patch on top for BFS to build:
bfs422-nohotplug_fix.patch
Thanks!
ReplyDeletethanks2 (valeu)
ReplyDeleteThanks for work Con.
ReplyDeleteBut a problem with build new patch on kernel 3.4.0 after apply this patch : http://ck.kolivas.org/patches/3.0/3.4/3.4-ck1/patch-3.4-ck1.bz2
kernel/sched/bfs.c: In function 'try_preempt':
kernel/sched/bfs.c:1458:3: error: 'cpu_online_map' undeclared (first use in this function)
kernel/sched/bfs.c:1458:3: note: each undeclared identifier is reported only once for each function it appears in
Thanks, apologies I didn't try building on SMP without CPU hotplug enabled since that's on most configs these days. I put a hotfix patch in the top post for this.
DeleteThis comment has been removed by the author.
ReplyDeleteThanks also from me Con, running happily on slackware64-current, with also BFQ patch applied.
ReplyDeleteAs I reiceived my raspberry pi a few days ago and I'm a very curious person, I will try the ck patch with BFQ also there (ARMv6): unfortunately their kernel is stuck at 3.1.9, but I think checking if the older patch works won't hurt :)
https://github.com/raspberrypi
I was wondering if anyone has tested BFS alone vs the full patches? Just wondering if responsiveness is significantly affected or not.
ReplyDeleteThank you very much for the update, Con!
ReplyDeleteThanks Con, now I can release 3.4 Optimus Kernel http://iqunix.blogspot.com :)
ReplyDeleteHi Con
ReplyDeleteOne question:
i found a one problem with kernel 3.2 to 3.4
the cpu load is to big
in 3.2.18 kernel with BFS and BFQ is (vmstat status)with 700-800MB/s id is 92-95%:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 328892 91556 2283632 0 0 1 21 1 14 3 3 94 0
2 0 0 328504 91556 2283632 0 0 0 0 120738 32114 3 2 95 0
0 0 0 328136 91556 2283632 0 0 0 0 120387 36606 4 3 93 0
1 0 0 327712 91556 2283632 0 0 0 0 123983 40816 4 3 92 0
0 0 0 327280 91556 2283632 0 0 0 0 121481 35196 4 2 94 0
0 0 0 327016 91556 2283632 0 0 0 0 121561 35766 3 3 94 0
0 0 0 326744 91556 2283632 0 0 0 0 121226 31580 3 2 95 0
1 0 0 326248 91556 2283632 0 0 0 0 123612 33543 3 4 93 0
1 0 0 325720 91556 2283632 0 0 0 536 120555 30877 3 2 95 0
But in kernel 3.4.0 with latest BFQ and BFS load in cpu is too big IDLE is 58-65%:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 2619944 43080 590332 0 0 265 224 12917 2198 6 26 62 5
0 0 0 2619852 43080 590332 0 0 0 0 180064 10918 4 38 58 0
0 0 0 2619728 43080 590332 0 0 0 0 181218 10440 2 38 60 0
0 0 0 2619480 43080 590332 0 0 0 0 179684 10429 1 37 62 0
0 0 0 2618968 43080 590332 0 0 0 0 176243 9484 1 35 64 0
0 0 0 2618224 43080 590332 0 0 0 0 174315 12337 2 35 63 0
1 0 0 2617728 43088 590324 0 0 0 20 172040 10340 1 35 64 1
0 0 0 2617248 43088 590332 0 0 0 0 173837 9762 1 34 65 0
0 0 0 2616860 43088 590332 0 0 0 0 173639 10090 1 35 63 0
May by this a bug with sched or is a kernel change bug ?
@Micron: sorry, have you tried without bfq?
ReplyDeleteI think it's difficult to blame one of the two if you don't do separate tests.
Hope not to be too much off-topic, but raspberrypi's 3.1.9 kernel seems to perform better with bfs-415 and latest bfq \o/
6 hours for building it :o
(but now I'm starting to implement distcc with an appropriate toolchain on my other hosts, and if it works things surely will get better)
@ponce:
DeleteI test with remove bfq and bfs and differ problem problem with performence in kernel 3.3 and 3.4 in kernel 3.2 performence is ok.
in kernel 3.1 have a problem with load and lag in internet.
i write to Con may by find where the problem.
@CK - thanks for this release and I hope things settle down for you @work. That kind of shit is never fun.
ReplyDeleteGot a potential bug to report with this release of BFS: no sysload even when compiling on a quad core with 4 threads:
$ uptime
15:58:10 up 7:52, 2 users, load average: 0.00, 0.00, 0.00
$ cat /proc/loadavg
0.00 0.00 0.00 6/336 31689
On the plus side, there does not appear to be any performance regression using my standard make benchmark comparing both the bfs 0.420 in 3.3.7 and bfs 0.422 in 3.4.0:
Link to ANOVA.
Blogspot STILL does not let me post f*cking images!!!
Your HTML cannot be accepted: Tag is not allowed: IMG
I confirm the system load bug. It's a constant 0/0/0 here too.
DeleteI knew I could get that system load down. Success!
DeleteLOL
DeleteThis comment has been removed by the author.
DeleteHa! Do you think this "0.0 bug" has the same cause as the htop issue you and I have been talking about in email, CK?
DeleteOn Mon, 26 Mar 2012 16:09:06 you wrote:
> http://sourceforge.net/tracker/?func=detail&atid=651633&aid=3511139&group_id
> =108839
>
> Here is his reply. Do you have any ideas based on his info?
> For processes:
> First I calculate the "CPU period" value: totalPeriod / numberOfCpus.
> Then, for each process, I read utime and stime from their
> /proc//stat file. Then I do this:
> CPU = (utime+stime-prevUtime-prevStime) / cpuPeriod * 100
Knowing where he gets his data from is helpful. What to do about it is another
matter, with the usual equation of time and priority placing this very low for
now, but I will look at it at some stage.
The 0.0 load bug is a new one unrelated to the system time bug of previous BFS releases. I will be working on it soon.
DeleteSorry, I should have posted details about the make benchmark:
ReplyDelete1) It is a non-latency based measure.
2) Compilation benchmark using gcc to “make bzImage” for a preconfigured linux 3.4 build.
3) Runs the two individual benchmarks ten (10) times totally to get a decent number of observations for a statistical comparison. In all cases, the first run is omitted leaving an n=9.
4) Results are how many seconds it took to compile on a dual Intel E5620 (2x hyperhreaded quadcore CPUs on a single board).
5) Make is run with 16 threads (8 physical cores and 8 HT cores).
This comment has been removed by the author.
ReplyDeleteI'm also getting that 0 load across all 3 averages and I doubt the problem has anything to do with htop.
ReplyDeleteAlso got a kernel panic in my VM with a 3.4(.1? I honestly can't remember) bfs kernel, no I don't have the dump from that so I'm being completely unhelpful in that regard.
Considering all the problems it's back to 3.3.8 for me, if absolutely necessary I can load 3.4.x back up again and throw a few kernel builds at it until it panics again (if I have some free time later I'll try and do that). It's very possible that the problem could have to do with BFQ as well so I would have to redo that again without those patches and see what's up.
Zero load..
DeleteHow about mainline?If mainline do so, that means this is not a sched bug.
It only happens with bfs in 3.4.x.
Delete@ Ralph Ulrich,
ReplyDeleteIf you're around here, please, answer the last question addressed to you in the previous Blog posting. Thank you in advance!
Manuel Krause
Why do I need SLUB all of the sudden? Only for your scheduler to work? Heh?! SLAB worked for me with your patchset for years now.
ReplyDeleteManuel Krause
Just for enhancing...
DeleteEnjoy your kernel panics with SLAB. :P
DeleteI think the idea is that he really doesn't have time to track down why exactly it's causing problems for SLAB. It could also be that he just doesn't care enough to find out which is also acceptable considering I don't think many people really care about SLAB anymore.
Just like anything else things change over time, including the linux kernel and bfs. Just because something worked in the past (for years) doesn't mean it will work with the next kernel revision.
SLUB has been the default now for a while and should be better than SLAB in basically every way.
O.k. Thanks for your explanations. :-)
DeleteAt least everything seems to work as expected & as well as before.
Manuel Krause
Who posted my text to lkml about the 0 sysload bug?
ReplyDeletehttps://lkml.org/lkml/2012/6/9/92
I did not. But if a (seemingly chaotic) guy has time to put some work into BFS this could help. For me that bug began with linux-3.3-bfs showing a near thousand percentage overload. To turn off any meaningful feedback from the kernel for me is not an alternative.
ReplyDeleteRalph Ulrich