Thursday, 11 August 2011

3.0.0-ck1 and BFS for 3.0.0

Surprise, I'm back and it's all ready.

http://ck.kolivas.org/patches/bfs/3.0.0/3.0-sched-bfs-406.patch

http://www.kernel.org/pub/linux/kernel/people/ck/patches/3.0/3.0.0-ck1/

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...
Posted by at
Labels: , ,

66 comments:

  1. Unknown11 August 2011 at 15:19

    Works fine using Gentoo's 3.0.1 kernel.

    ReplyDelete
  2. ren11 August 2011 at 16:17

    "Goddamn we (collectively, the developed world) screwed that country up big..."

    Not just that one unfortunately...

    Thanks for BFS 3

    ReplyDelete
  3. CenT11 August 2011 at 21:39

    Hello, thank you for this work, we can use on the version 3.0.1 without problems?

    ReplyDelete
  4. ck11 August 2011 at 21:44

    Yes it should apply and work fine (as realnc said above)

    ReplyDelete
  5. Micron12 August 2011 at 00:02

    Yes all is oki work fine on 3.0.1
    Бut when will it have the 3.1, there were many major changes.

    ReplyDelete
  6. Anonymous12 August 2011 at 03:39

    What about these patches?

    http://ck-hack.blogspot.com/2011/06/2639-ck2-bfs-0406.html#c8053760710835784618

    http://ck-hack.blogspot.com/2011/06/2639-ck2-bfs-0406.html#c2778747879546520999

    ReplyDelete
  7. ck12 August 2011 at 07:00

    I wanted the merge to 3.0 to be relatively risk free. I'll look at them shortly.

    ReplyDelete
  8. Anonymous12 August 2011 at 10:30

    Great job, CK. Welcome home!

    $ dmesg | grep BFS
    [ 0.569589] BFS CPU scheduler v0.406 by Con Kolivas.

    ReplyDelete
  9. tux965612 August 2011 at 13:32

    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
  10. ck12 August 2011 at 14:56

    That's somewhere between bizarre, amusing and really disappointing at the same time. Thanks very much for the feedback.

    ReplyDelete
  11. Ralph Ulrich12 August 2011 at 18:26

    @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
  12. Ralph Ulrich12 August 2011 at 18:44

    @ck, diff tells me, you have done some work on

    sched_domain
    do_set_cpus_allowed
    cpu_mask

    LinuxContainers should be possible to run with BFS !? (Ask me, how is it the BFS patch shortened since 2.6.39 :)

    ReplyDelete
  13. ck12 August 2011 at 19:43

    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
  14. ponce12 August 2011 at 19:55

    @Ralph: FYI, I'm running LXC containers now: slackware64-current with lxc-0.7.5 and 3.0.1-ck1 ;)
    here they worked fine also on previous bfs releases...

    ReplyDelete
  15. Ralph Ulrich12 August 2011 at 21:18

    @ck gcc-4.6.1 changed behavior not including indirects

    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[3]: *** [/src/linux-3.0/usr/include/linux/.check] Error 123
    make[2]: *** [linux] Error 2
    make[1]: *** [headers_check] Error 2

    ReplyDelete
  16. Ralph Ulrich12 August 2011 at 21:46

    compiles unsetting CONFIG_HEADERS_CHECK

    If there are missing includes using gcc-4.6.1 - I don't know if external modules (vbox,nvidia) will do ...

    ReplyDelete
  17. Alan12 August 2011 at 22:28

    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:

    linux-image: http://www.mediafire.com/?95kwze5c71i5764
    linux-headers: http://www.mediafire.com/?7ydf93cg4plotd1

    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.

    ReplyDelete
  18. ponce12 August 2011 at 22:50

    gotta correct myself, CONFIG_SCHED_BFS excludes CONFIG_CGROUP_SCHED.

    ReplyDelete
  19. Anonymous12 August 2011 at 22:53

    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.

    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.

    ReplyDelete
  20. Anonymous12 August 2011 at 22:58

    @ anon:
    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

    ReplyDelete
  21. ck12 August 2011 at 23:01

    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
  22. Anonymous13 August 2011 at 00:50

    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
  23. Anonymous13 August 2011 at 01:07

    @ Anon :: 10:58 PM
    Thank you for the response, I guess I could use noop IO scheduler until BFQ gets patched.

    ReplyDelete
  24. Martin13 August 2011 at 07:00

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

    So thanks to Con and Paolo for their good work on the schedulers. :-)

    ReplyDelete
  25. Unknown16 August 2011 at 19:34

    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
  26. karabaja416 August 2011 at 22:58

    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.

    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.

    ReplyDelete
  27. karabaja417 August 2011 at 04:51

    Also, I'm experiencing some small stutters every 1 or 2 minutes while playing OpenArena, like very small freezes here and there.

    ReplyDelete
  28. Det24 August 2011 at 22:35

    The -pf patchset already includes BFQ (along with -ck1, TuxOnIce and a mainline update)

    See here: http://pf.natalenko.name/sources/3.0/ (not for 3.0.3 yet, though).

    ReplyDelete
  29. Anonymous25 August 2011 at 00:46

    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
  30. Mike27 August 2011 at 00:28

    The Zen-Kernel in Version 3.0.3 does include the BFQ too. Using it here with BFS and BFQ enabled.

    CU sysitos

    ReplyDelete
  31. nous27 August 2011 at 08:18

    @CK BFS breaks tuxonice resume from hibernation when LZO or LZF compression is applied. This started from 2.6.39.3 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
  32. ck27 August 2011 at 08:26

    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
  33. nous27 August 2011 at 08:49

    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
  34. ck27 August 2011 at 08:53

    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
  35. karabaja428 August 2011 at 02:04

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

    If you could do something for either of these bugs that would be awesome :)

    Cheers!

    ReplyDelete
  36. ck28 August 2011 at 14:15

    @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
  37. Anonymous29 August 2011 at 01:35

    I heard cgroups are needed for CFS, but what about BFS? Can I safely disable config_cgroups? Thanks.

    ReplyDelete
  38. karabaja429 August 2011 at 07:52

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

    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?

    ReplyDelete
  39. karabaja429 August 2011 at 09:36

    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
  40. karabaja429 August 2011 at 23:45

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

    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.

    ReplyDelete
  41. karabaja429 August 2011 at 23:49

    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
  42. towheedm30 August 2011 at 07:27

    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.

    Also got the error:
    /usr/src/linux-3.0/usr/include/linux/sched.h:1016: included file 'asm-x86/current.h' is not exported

    ReplyDelete
  43. ck30 August 2011 at 08:01

    @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
  44. karabaja430 August 2011 at 09:49

    @CK: not using DE (just plain Openbox WM), I have compositing disabled.

    ReplyDelete
  45. Anonymous31 August 2011 at 21:13

    @karabaja4: You see the same bug with pure 3.0. So how is it a BFS problem?

    ReplyDelete
  46. karabaja431 August 2011 at 22:37

    @Anonymous: Where did I write that? I don't see it with CFS on 3.0.

    I said I see it on pure kernel patched with BFS patch _only_, without the additional 3.0 -ck patches.

    ReplyDelete
  47. Anonymous5 September 2011 at 02:56

    people with small freezes (kernel 3.0.x), maybe related to https://bugzilla.kernel.org/show_bug.cgi?id=40262

    ReplyDelete
  48. Unknown5 September 2011 at 20:26

    And this is the patch if you want to try:

    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=4508378b9523e22a2a0175d8bf64d932fb10a67d;hp=1af8efe965676ab30d6c8a5b1fccc9229f339a3b

    ReplyDelete
  49. Anonymous7 September 2011 at 23:35

    Any plans to tidy up usage of long and int if that's beneficial on less powerful CPU's?

    ReplyDelete
  50. ck7 September 2011 at 23:38

    Guaranteed it would not make a difference measurable by any means on the planet.

    ReplyDelete
  51. Anonymous9 September 2011 at 03:37

    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
  52. Anonymous9 September 2011 at 13:44

    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
  53. Anonymous9 September 2011 at 23:12

    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.

    There is neither a need to rely on the happenstance nor any benefit.

    ReplyDelete
  54. Unknown10 September 2011 at 02:29

    "Int is the most natural integer for a given arch and is tied to word."

    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.

    ReplyDelete
  55. Anonymous10 September 2011 at 03:34

    I still think that BFS abuses long and long long.

    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.

    ReplyDelete
  56. ck10 September 2011 at 07:25

    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
  57. Anonymous10 September 2011 at 13:14

    Apology accepted.

    ReplyDelete
  58. L.J.Marín11 September 2011 at 08:24

    @CK: Hi,

    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?

    ReplyDelete
  59. Unknown11 September 2011 at 20:26

    @L.J.Marín
    BFS has nothing to do with this. You should learn how to build kernels :-P

    ReplyDelete
  60. L.J.Marín14 September 2011 at 11:44

    @RealNC :P

    I've learned,
    the problem is, the last kernel (2.6) work very fine,
    now, 3.0 not work very fine,
    is the same config :)

    ReplyDelete
  61. Unknown15 September 2011 at 04:29

    Did you remember to do "make oldconfig" after applying the BFS patch?

    ReplyDelete
  62. L.J.Marín17 September 2011 at 11:46

    Yes, I tried too :(
    no have case,
    I still use default config :/
    Thanks my friend.

    ReplyDelete
  63. ck20 September 2011 at 14:10

    Indeed apology was sarcasm, but I was going to get around to it, eventually.

    ReplyDelete
  64. ermes2 October 2011 at 07:26

    hi all
    I need patch-3.0.0-ck1.bz2 but kernel.org is down, where can i download it?
    thanks

    ReplyDelete
  65. chronniff19 October 2011 at 08:32

    me too, I need this ck patch too, is there anywhere else I can find it?

    ReplyDelete
  66. chronniff19 October 2011 at 08:36

    nevermind, got it here http://ck.kolivas.org/patches/3.0/patch-3.0.0-ck1.gz

    ReplyDelete

Subscribe to: Post Comments (Atom)