Surprise, I'm back and it's all ready.
Note no packages this time because the current distributions get really confused thanks to the new numbering and may not boot.
Nauru was a very depressing place indeed, really living up to the expectations I had based on what I knew of the history of it. Goddamn we (collectively, the developed world) screwed that country up big...
Works fine using Gentoo's 3.0.1 kernel.ReplyDelete
"Goddamn we (collectively, the developed world) screwed that country up big..."ReplyDelete
Not just that one unfortunately...
Thanks for BFS 3
Hello, thank you for this work, we can use on the version 3.0.1 without problems?ReplyDelete
Yes it should apply and work fine (as realnc said above)ReplyDelete
Yes all is oki work fine on 3.0.1ReplyDelete
Бut when will it have the 3.1, there were many major changes.
What about these patches?ReplyDelete
I wanted the merge to 3.0 to be relatively risk free. I'll look at them shortly.ReplyDelete
Great job, CK. Welcome home!ReplyDelete
$ dmesg | grep BFS
[ 0.569589] BFS CPU scheduler v0.406 by Con Kolivas.
Thank you! It's nice to have bfs on 3.0.x. I was using 3.0 for a while for the improvements to btrfs performance but I just couldn't stand the terrible responsiveness when compiling or compressing stuff in the background. I actually went back to 2.6.39-ck2 and just dealt with the slower btrfs performance. Yes, bfs is really that much better compared to the stock scheduler.ReplyDelete
That's somewhere between bizarre, amusing and really disappointing at the same time. Thanks very much for the feedback.ReplyDelete
@ck, I speculated in your previous blog, this BFS for linux-3.0 is difficult, because of a few new flags in the official scheduler which is for Linux Containers. Did you implement all this in BFS also?ReplyDelete
@ck, diff tells me, you have done some work onReplyDelete
LinuxContainers should be possible to run with BFS !? (Ask me, how is it the BFS patch shortened since 2.6.39 :)
As per usual BFS practice, I... ignored features that are absolutely meaningless, useless, and more importantly inappropriate on the desktop. So - no, there is no support for any new features, just the same reliable predictable simple BFS which just plain works. I spent some time updating the sched domains code to be in line with the latest mainline and deleted stuff which is irrelevant to BFS which is why it's even smaller.ReplyDelete
@Ralph: FYI, I'm running LXC containers now: slackware64-current with lxc-0.7.5 and 3.0.1-ck1 ;)ReplyDelete
here they worked fine also on previous bfs releases...
@ck gcc-4.6.1 changed behavior not including indirectsReplyDelete
compile Error using gcc-4.6.1
/src/linux-3.0/usr/include/linux/sched.h:1016: included file 'asm-x86/current.h' is not exported
/src/linux-3.0/usr/include/linux/sched.h:1575: userspace cannot reference function or variable defined in the kernel
/src/linux-3.0/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernel
make: *** [/src/linux-3.0/usr/include/linux/.check] Error 123
make: *** [linux] Error 2
make: *** [headers_check] Error 2
compiles unsetting CONFIG_HEADERS_CHECKReplyDelete
If there are missing includes using gcc-4.6.1 - I don't know if external modules (vbox,nvidia) will do ...
I compiled some 3.0.1-ck1 debs on Ubuntu 11.04 Natty (x86_64) for personal use, but I'd be more than happy to share:ReplyDelete
Running for over 1 day now on several Lenovo T410/T420 ThinkPads and an HP Z400, all with Nehalem-based Core i7/Xeon processors, nvidia and vbox modules confirmed working.
Hope that helps someone! As always, thanks, Con.
gotta correct myself, CONFIG_SCHED_BFS excludes CONFIG_CGROUP_SCHED.ReplyDelete
I was streaming video to internet other day, and the stream lagged really horribly using stock 3.0 kernel, so I had to go back to my 2.6-ck kernel.ReplyDelete
Thanks for this, btw are you doing BFQ too?
The stock IO scheduler locks completely my system when moving from HDD to HDD, haven't tested on 3.0 however. BFQ Fixed all these problems and more in the past.
A few days ago I asked Paolo Valente (BFQ's developer) about it and he said he's "trying to find the time" to port it to 3.0.
Guess we'll have to wait until a "3.0" appears in http://algo.ing.unimo.it/people/paolo/disk_sched/patches/
or perhaps an announcement here: http://groups.google.com/group/zen_kernel
Hmm... based on my purely anecdotal unquantifiable yardstick of the reports so far here, it appears mainline 3.0 is actually worse than the last few kernels.ReplyDelete
Well one doesn't have to look at benchmarks to verify that linux kernels are gettings worse by the month. Each new release is slower than the previous one, there are months (years?) old unfixed power problems and other issues, but people insist on working on numa stuff instead of fixing existing problems for everyday use. But stuff that actually make it work better - like bfs or bfq - is excluded from the official kernel. Bah...ReplyDelete
@ Anon :: 10:58 PMReplyDelete
Thank you for the response, I guess I could use noop IO scheduler until BFQ gets patched.
@ Anon: the i915 driver stack is another example of degrading or at least non-improving software. I still have spurious segfaults and kernel freezes on two out of three machines.ReplyDelete
So thanks to Con and Paolo for their good work on the schedulers. :-)
Maybe it's a good idea to create a version control repo for BFS, even if version control isn't the way CK works. I say this because BFS right now pretty much depends on one person. A proper "project" might result in a proper community of developers around BFS over time. It really might be worth the effort to start a project on something like SourceForge or whatever.ReplyDelete
One small bug I noticed and it's pretty recent, I don't know exactly when it started happening (because I wasn't using BFS for some time), but it happens on 3.0 and BFS 0.406.ReplyDelete
With VDPAU (nvidia) video decoding, when resizing video from fullscreen back to windowed by double clicking the video in smplayer, the transition is incredibly sluggish. It takes maybe 1.5 seconds do it, and you can see parts of the GUI appearing sporadically before it resizes (the video slider etc), and in the process video stops running (annoying when you have seperate sound track running synchronized elsewhere, don't ask why :D). This doesn't happen on CFS.
Also, I'm experiencing some small stutters every 1 or 2 minutes while playing OpenArena, like very small freezes here and there.ReplyDelete
The -pf patchset already includes BFQ (along with -ck1, TuxOnIce and a mainline update)ReplyDelete
See here: http://pf.natalenko.name/sources/3.0/ (not for 3.0.3 yet, though).
Nice, but I wonder where did pf get BFQ for 3.x, it hasn't been released yet. It could be a simple port of the 2.6.x version.ReplyDelete
The Zen-Kernel in Version 3.0.3 does include the BFQ too. Using it here with BFS and BFQ enabled.ReplyDelete
@CK BFS breaks tuxonice resume from hibernation when LZO or LZF compression is applied. This started from 22.214.171.124 onwards. Stock kernels with just tuxonice work fine. Related discussions can be found at the Archlinux and Gentoo forums from users of the pf-patchset (ck+tuxonice+bfq). See https://bbs.archlinux.org/viewtopic.php?pid=963183#p963183 and below for more.ReplyDelete
About tuxonice: That's a real shame. It's enough hard work for me to keep in sync with the mainline changes. It's nigh on impossible for me to try and keep in sync with all other out-of-mainline patches (yes I do see the irony given -ck is out-of-mainline too).ReplyDelete
I wouldn't expect otherwise and, anyway, it was a tuxonice update that broke it. I just find it funny that a scheduler would affect lzo decompression.ReplyDelete
Well freezing all the tasks and putting the scheduler in a state where the suspend process can proceed is EXTREMELY non-trivial, so just about any sort of interaction can happen that breaks suspend / resume. Last I saw, the compression is done in weird ways like disabling interrupts. Just about anything bad might happen like that :(ReplyDelete
@CK: do you have any info on two problems I posted above? VDPAU is kinda closed source and all, it depends solely on nvidia's ability to code it right so it works with BFS. But why would Openarena stutter? As stated above, I'm experiencing small mini-freezes every minute or so.ReplyDelete
If you could do something for either of these bugs that would be awesome :)
@karabaja4:Unfortunately I have no idea. Are you using just BFS or -ck? Are you using the ondemand power governor? Have you enabled the zcache compressed ram cache thingy?ReplyDelete
I heard cgroups are needed for CFS, but what about BFS? Can I safely disable config_cgroups? Thanks.ReplyDelete
@CK: I am using -ck (Archlinux AUR), but there is no BFQ for 3.0 yet (it's commented out), so for now -ck includes only BFS. I am not using ondemand power governor or compressed ram cache, pretty much default mainline kernel with BFS and it's recommended settings (ticks off, preempt on, timer 1000).ReplyDelete
P.S. Do you by any chance have a nvidia card capable of vdpau so you could either try to reproduce the vdpau bug or openarena bug with nvidia blob drivers?
P.P.S. Oh, I just figured out that BFS and CK patchsets are actually different. I will test the BFS patch and report.ReplyDelete
I tested pure BFS without the extra -ck patches. Both bugs are still there, although it may be that openarena freezes are less often, and when they do happen the freeze time is a bit shorter (I think).ReplyDelete
Sorry, I mixed up things in above posts, I though -ck includes BFQ by default. I now see that -ck is in fact BFS but with lots of mini-patches. Anyway, I tested both and its roughly the same.
One more thing I noticed about the vdpau bug, when moving smplayer window around, CPU goes insane and movements are VERY choppy.
P.S. Another game where mini-freezes are way more visible (because the game itself is very fluid) is Extreme Tux Racer (try track "Who said Penguins Can'f Fly").ReplyDelete
Getting a lot of '/usr/src/linux-3.0/usr/include/linux/sched.h:xxxx: userspace cannot reference function or variable defined in the kernel' errors with 'make headers_check'. It does not happen with the stock 3.0.0 kernel.ReplyDelete
Also got the error:
/usr/src/linux-3.0/usr/include/linux/sched.h:1016: included file 'asm-x86/current.h' is not exported
@karabaja4: Are you running kde? Perhaps you're running into the kde + compositing + nvidia issue? It hits far more frequently on BFS than mainline. If so, try a different desktop environment?ReplyDelete
@CK: not using DE (just plain Openbox WM), I have compositing disabled.ReplyDelete
@karabaja4: You see the same bug with pure 3.0. So how is it a BFS problem?ReplyDelete
@Anonymous: Where did I write that? I don't see it with CFS on 3.0.ReplyDelete
I said I see it on pure kernel patched with BFS patch _only_, without the additional 3.0 -ck patches.
people with small freezes (kernel 3.0.x), maybe related to https://bugzilla.kernel.org/show_bug.cgi?id=40262ReplyDelete
And this is the patch if you want to try:ReplyDelete
Any plans to tidy up usage of long and int if that's beneficial on less powerful CPU's?ReplyDelete
Guaranteed it would not make a difference measurable by any means on the planet.ReplyDelete
16-bit arches would crawl. Let me put the question differently. What's the realistic range of numbers BFS explores while using long. I know that number of CPUs is proclaimed to be less than 4092. :)ReplyDelete
What the heck are you talking about? Linux only runs on 32 and 64 bit platforms and long and int are the same size on 32bits. They're only different on 64 bit platforms and there is zero speed advantage to int over long, just slight size difference.ReplyDelete
Int is the most natural integer for a given arch and is tied to word. Long simply happens to be equal to int on 32/64 bit.ReplyDelete
There is neither a need to rely on the happenstance nor any benefit.
"Int is the most natural integer for a given arch and is tied to word."ReplyDelete
Not really. Neither the C nor C++ standards say anything about it. As a result, it's compiler-specific as well as system specific. GCC on Intel x86-64 has a 32-bit int while the native word size is 64-bit (long). Other compilers and GCC on other architectures can (and do) behave differently.
I still think that BFS abuses long and long long.ReplyDelete
C99 6.2.5 (5) does explicitly say that int is the natural type for a given architecture.
This is worth cleaning. There are patches posted in another thread that begin to address this.
The fact that long happens to be equal to int does not excuse the bad practice.
The long longs are absolutely necessary and the ints are the same size as the longs. "Does not excuse the bad practice" - well excuse me for coding my brain fuck scheduler with bad practice.ReplyDelete
I use debian/testing, i used the new kernel 3.0 with the patch -ck.
The kernel result is a very big, 2GB +o- compare to 700mb +o-
The initrd is very big too, 90mb compare to 9mb.
Any idea for this?
BFS has nothing to do with this. You should learn how to build kernels :-P
the problem is, the last kernel (2.6) work very fine,
now, 3.0 not work very fine,
is the same config :)
Did you remember to do "make oldconfig" after applying the BFS patch?ReplyDelete
Yes, I tried too :(ReplyDelete
no have case,
I still use default config :/
Thanks my friend.
@other anonymous: are you really such a moron to think you deserve an apology, or that he was actually apologizing for something that is your bullshit view of what's important that he rightfully doesn't care about?ReplyDelete
Indeed apology was sarcasm, but I was going to get around to it, eventually.ReplyDelete
I need patch-3.0.0-ck1.bz2 but kernel.org is down, where can i download it?
me too, I need this ck patch too, is there anywhere else I can find it?ReplyDelete
nevermind, got it here http://ck.kolivas.org/patches/3.0/patch-3.0.0-ck1.gzReplyDelete
Is this patch available somewhere? It's needed for a custom kernel for an Android device. Newer kernels don't work on the device as of now.ReplyDelete