Saturday, 2 June 2012

BFS 0.422, 3.4.0-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

31 comments:

Thanks for work Con.But 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 also from me Con, running happily on slackware64-current, with also BFQ patch applied.

As 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 :)

@Micron: sorry, have you tried without bfq?I 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:I 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.

Ha! 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?

On 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 * 100Knowing 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.

1) 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).

I'm also getting that 0 load across all 3 averages and I doubt the problem has anything to do with htop.

Also 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.

I 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.

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. Ralph Ulrich