Friday 11 November 2011

3.1.0-ck2, BFS 0.415

Blah blah fixes blah blah rollbacks, anyway here's a new -ck and bfs 415. Nothing new here, just bugfixes.

3.1.0-ck2

3.1-sched-bfs-415.patch


Full -ck patchlist:

3.1-sched-bfs-414.patch
sched-add-above-background-load-function.patch
mm-minimal_swappiness.patch
mm-enable_swaptoken_only_when_swap_full.patch
mm-drop_swap_cache_aggressively.patch
mm-kswapd_inherit_prio-1.patch
mm-background_scan.patch
mm-idleprio_prio-1.patch
mm-lru_cache_add_lru_tail-1.patch
mm-decrease_default_dirty_ratio.patch
kconfig-expose_vmsplit_option.patch
hz-default_1000.patch
hz-no_default_250.patch
hz-raise_max.patch
preempt-desktop-tune.patch
cpufreq-bfs_tweaks.patch
bfs414-noprefetch.patch
bfs414-remove_rqpreempt.patch
bfs414-correct_int_size.patch
bfs414-stickybool.patch
bfs414-dont_use_task.patch
bfs414-clear_deactivated_sticky.patch
bfs414-fix-nonbfs-build.patch
bfs414-415version.patch
ck2-version.patch 
 
 
BFS 415 is now the following patches from -ck2 above:
 
3.1-sched-bfs-414.patch
sched-add-above-background-load-function.patch
cpufreq-bfs_tweaks.patch
bfs414-noprefetch.patch
bfs414-remove_rqpreempt.patch
bfs414-correct_int_size.patch
bfs414-stickybool.patch
bfs414-dont_use_task.patch
bfs414-clear_deactivated_sticky.patch
bfs414-fix-nonbfs-build.patch
bfs414-415version.patch 
 
Enjoy!

47 comments:

  1. Thanks ck! Bug fixes are not bad, it make the code more stable.

    ReplyDelete
  2. :) blah blah bug fix :) and go to build new CK to kernel.

    ReplyDelete
  3. CK - thanks for the release. I ran the usual make benchmark against 3.1 with ck1 and 3.1 with ck2 (n=27) - there are no statistically significant differences in the compile times. Good job as always!

    ReplyDelete
  4. [Ralph Ulrich]
    Yeah, patches and runs well using linux-3.1.1 (this new point release has made it on the front page of kernel.org - before 3.1 was neglected).

    ReplyDelete
  5. Here are the data:

    http://s10.postimage.org/ewhwamyhz/compare.png

    ReplyDelete
  6. Is it possible to create 415 for 3.0.9 ?

    ReplyDelete
  7. 415 offers nothing for linux-3.0.x. After 406, all the changes are to work with linux-3.1.x. and trivial changes. I recommend anyone on 3.0.x not try to upgrade from 406.

    ReplyDelete
  8. [Ralph Ulrich]
    Recently I had experienced some micro stalls during heavy IO (when Gentoo emerge was ready and actually installing the packages). This was not for linux-2.6.39-bfs (I don't know for sure if this happened with linux-3.0-bfs).

    What variables can I edit and change in the source to punish heavy IO tasks?
    Or, even better, can I change some runtime config?

    If throughput performance drops significantly I don't care: I would like to NOT notice my heavy backgroud tasks!
    I already use "compile --jobs=1" on an Intel Duo Core, also I know this nearly doubles compile time, I just don't want to notice these ....

    ReplyDelete
  9. Ralph, you should look into schedtool and ionice. You could also experiment with the BFQ I/O scheduler to see if it helps in your workload.

    ReplyDelete
  10. [Ralph Ulrich]
    I will not use these BFQ patches. Because I know what a hazardious framework IO is, I simply don't trust.

    Once in a while I looked into BFS patch diffs. I remember there was dirty IO punishment for tasks in there, has something changed ?

    ReplyDelete
  11. For Gentoo's emerge not to affect interactivity, you should emerge "sys-process/schedtool" and then use these two lines in your /etc/make.conf:

    PORTAGE_NICENESS=19
    PORTAGE_IONICE_COMMAND="sh -c \"schedtool -D \${PID}; ionice -c 3 -p \${PID}\""

    With this, emerging anything will be totally transparent and will not impact performance in any way.

    ReplyDelete
  12. I always use batch scheduling (man schedtool) when I run compiles. From the description it has longer timeslices but nearly always preempts when requested. Perfect for cpu intensive background tasks.

    ReplyDelete
  13. This is what I do: in my .profile and .bashrc I added

    if [ "$TERM" = "xterm" ]; then
    schedtool -D $$
    ionice -c 3 -p $$
    fi

    That way I can do the most intensive builds in my terminal windows with zero impact on the desktop.

    On single cpu machines I found the background processes starving too much, so I tend to use renice 19 > /dev/null instead.

    scheduling groups, pffft, who needs them. ;)

    ReplyDelete
  14. Hey CK,

    just wanted to report, that bug I was reporting before, stuttering when decoding video material - dissapeared when I replaced my Athlon 64 single core with Athlon 64 dual core (it is basically the same processor type and arhitecture, just with two cores). So you might want to check if there was some bug with single core logic and video decode related scheduling...

    Cheers,
    karabaja4

    ReplyDelete
  15. Hi CK,

    my machine is very old, a P III 1400 (Tualatin), TUV4X-Chipset, 2GB Kingston SDRAM, 2 IDE-HDDs, swapfile 4GB on second disk, shmfs 3GB mounted. OS is an openSUSE 11.4 running with one of the latest kernel-sources provided by openSUSE as .rpm (these are themselves patched somehow) + bfs-313.autoiso-xorg.patch + patch-3.1.0-ck2 (modified for openSUSE) + the three BFQ patches. => 3.1-ck2. KDE 4.7.3. XOrg 1.10.4.

    I use the shmfs to decode encrypted video files from another partition (1st disk) to it, cut them with Avidemux, and code them back to the original partition (after deletion of the original file).
    Whenever the file's size exceeds 1GB I experience heavy stuttering within the KDE-Desktop, mouse not responding, and background processes like BOINC (running at "schedtool -D") starving (observed wit gkrellm).

    Another maybe somehow linked thing: The only way --so far-- to prevent the system from going out for lunch for more than two hours (_no_ responsiveness) was to generally set
    swappiness=60 and
    dirty_ratio=20 (the vanilla defaults).

    WITH those settings responsiveness came back on here wiithin several minutes. But it's still not satisfiying.

    Need to add this: Stuttering/Starving does NOT go away with:
    vanilla kernel without CK&BFS without BFQ
    openSUSE kernel without CK&BFS without BFQ
    openSUSE kernel with CK&BFS without BFQ
    each of them with boot-time swappiness/dirty_ratio settings.

    Keep up on your good work,

    Manuel Krause
    (manuels-adresse@t-online.de)

    ReplyDelete
  16. CK,
    I think I'm encountering a bug in BFS. Basically sometimes a suspend-to-ram will take extra long (approx 8-15 seconds) and fail to resume properly. I have a Lenovo Thinkpad T410s running Archlinux. Standard kernel suspend always works. I have posted in more detail at https://bbs.archlinux.org/viewtopic.php?id=131498 any ideas would be greatly appreciated.

    ReplyDelete
  17. Hi Celtic_Jon. These suspend issues are always rather difficult to track down (but then so are all bugs related to the scheduler :\). Anyway I encountered a race condition myself in the pcmcia code that was exhibited pretty much only when BFS was running. I couldn't track it down exactly but it went away when I compiled pcmcia out of the kernel. If you're not using any pcmcia cards, try removing that option from your kernel perhaps. This is purely a long shot of course.

    ReplyDelete
  18. Hi CK,
    can you please comment on my posting from 2011-11-24? Or has it been 'too specific'?

    Best regards,
    Manuel Krause

    ReplyDelete
  19. @Manuel: Some kind of VM storm involving running out of ram and the kernel going nuts trying to figure out what to page out of ram and in. Try decreasing your swap space to something really small like 256MB.

    ReplyDelete
  20. @CK: ??? 2GB RAM, 4GB Swap partition, 3GB shmfs. There should be no VM storm at all! All things going to shmfs, that are not fitting into RAM, would swap out. O.k. But then, the recalls (or reclaims) should not stall the system.
    Decreasing my swapspace to <2048MB would disable my suspend-to-disk completely. What doesn't work on here either with 4GB swap partition. But that may be a radeon driver problem.
    Maybe, it's time to revive your good old "swap-prefetch" patches. I really liked them, but had no luck in reimplementig them.

    Manuel

    ReplyDelete
  21. I didn't say it was logical behaviour. I was just explaining what is likely happening, and I'd say it sucks too.

    ReplyDelete
  22. Hi CK, I tried compiling the kernel without pcmcia, but no luck. I'll just try BFS with new kernels now and again to see if it resolves. Thanks so much for all your hard work! :)

    ReplyDelete
  23. [Ralph Ulrich]
    There is some discussion at
    https://wiki.archlinux.org/index.php/Talk:Systemd
    cited there: CK says:
    "The cgroup features that aren't available with BFS will not appear when BFS is enabled. The rest of the cgroup features still work."

    As I understand this meant: BFS as a scheduler doesnt want to regard any cgroup setting for doing cpu core jobs priorities. But this does not mean cgroups as needed by systemd are not possible!

    In this arch-linux wiki about using systemd there is stated: "not supported BFS" patched Linux kernel.

    Systemd as a service manager is not about interfering any scheduler priorities! This misunderstanding should be clearified!

    Are there any cgroup config settings thinkable in /usr/src/linux/.config that could have bad influence on BFS?

    ReplyDelete
  24. No config options that are available should have any bad effects on BFS. If systemd makes cgroup support for features that BFS does not support a mandatory requirement then systemd becomes mutually exclusive with BFS. I can enable stubs that pretend the support is there in BFS but then that will just break things when systemd tries to use these interfaces. Systemd will be yet another one of those polarising technologies... sigh.

    ReplyDelete
  25. [Ralph Ulrich]Systemd is a service-management utility, BFS a scheduler. What features do you talk about?

    I do use an Linux-3.1.5 BFS patched kernel on a Debian-unstable with systemd as init in this moment of writing ...

    ReplyDelete
  26. Perhaps if you have NO cgroups enabled in your kernel then systemd will fail to load. Many of the cgroups features still work with BFS, except for some of the very scheduler specific ones.

    ReplyDelete
  27. [Ralph Ulrich] "The very scheduler specific" features of cgroups, such that the "famous" crgroup patch which Linus T. applauded for his compile jobs, are of no interest for systemd. Or, do I miss something in this regard?

    ReplyDelete
  28. @CK: Many thanks for your answer!
    Can there be an additional patch to reduce to-and-forth-swapping (in cases it won't be needed at all) with shmfs/swap relations?!

    Best regards,
    [Manuel Krause]

    ReplyDelete
  29. At this stage I'm considering abandoning the VM patches altogether in the future as the virtual memory subsystem is so messy and complex that it's getting impossible to predict how it's going to behave. So unfortunately the answer to that would be no.

    ReplyDelete
  30. [Ralph Ulrich] Also regarding the mm mv thing (I am not a kernel hacker):
    I mentioned above that I was hit by heavy IO, also I didn't experinced this before. I wonder if I had this because of the HugeTable feature: Was this relative new to linux? Due to the following artikel this is because of some background task delivering these huge pages. Though servers might profit, but me as desktop user, should I disable config-huge-pages?
    But this issue should be better with linux-3.2:
    http://lwn.net/Articles/467328/

    CK, is this something your mm patches are about?

    ReplyDelete
  31. Not directly, but there are definitely mainline VM patches that I'm looking forward to, like this No-I/O dirty throttling. Though it worries me seeing how complex this solution is :\

    ReplyDelete
  32. [Ralph Ulrich] By the way, not even a kernel hacker, I ever saw this complicatedness. This is why I never trusted out of mainline tree patches regarding IO (also no ck-mm patches for me). Also tuxonice project has just quited ...

    ReplyDelete
  33. Interesting patch (IO-less dirty throttling v12), thanks for the link!

    ReplyDelete
  34. @CK: I want to thank you very much for the link to these 11+(!) patches for IO-less-dirty-throttling, too! In version v12 they apply to 3.1.4 from openSUSE with CK2 and BFQ patches and compile and work fine.

    They are a great effort! Though they don't resolve my described issues with loaded shmfs+swap completely -- hickups in vlc-played videos appear less often and with much shorter delays when processing the huge video files as described above at the same time. Also the overall processing time gets reduced greatly as there are much fewer and also shorter stalls.

    Just wanted to let you know my first experience to that combo,
    Manuel Krause

    ReplyDelete
  35. Thanks for reporting back Manuel. You know you could actually help these I/O patches get into mainline linux kernel by reporting your testcase and results with/without this patchset applied to the linux kernel mailing list. The author of these patches is having trouble getting enough people to report that they're helpful. This is a common problem of course with regular user issues and linux kernel development. Don't be shy, they won't bite if you have a clear testcase like yours.

    ReplyDelete
  36. @CK: Thanks for informing me about these facts.
    My "testcase" is no benchmark at all and would/must fluctuate from day to day with files I need to decode+reencode (missing disk space). So the results would never be scientifically reproducible or "safe of proof" even on here.
    Though I don't have only just "subjective feelings" that things got much better with that patchset, I just looked at the clock and watched a video and that tells all about the progress. That's no environment+result kernel developers would ever accept. (I know that they bite from early reiserfs development.)

    Whom do I need to contact next before posting to LKML? Wu Fengguang, perhaps? Please, advise me!

    Also, I thought, these patches are already included into 3.2-rcs. Did I read too fast?

    Manuel Krause

    ReplyDelete
  37. I wrote to Wu Fengguang now with a 'short' explanation. Let's wait for his possible comment. This Combo works well, maybe I should increase file sizes over 1.3GB @shmfs ;-)

    Manuel Krause

    ReplyDelete
  38. Anyways, for running 3.1.* kernels, it's a worthy trial.

    Whether 3.2 comes @ X-Mas with it or without,

    Many thanks to Con!

    Manuel Krause

    ReplyDelete
  39. Great! it's been merged in 3.2, see for example Wu's code in https://github.com/torvalds/linux/blob/v3.2-rc6/mm/page-writeback.c

    ReplyDelete
  40. — Recently I've noticed some really insane values in sys part of timing: http://poige.livejournal.com/520776.html

    ReplyDelete
  41. Yep looks like there's some silly accounting bug in there. Don't know if/when/how I'll be able to fix it any time soon, sorry.

    ReplyDelete
  42. Perhaps someone knowledgeable enough here could look into it?

    Hope you can find the time to release a 3.2-based BFS though :)

    ReplyDelete
  43. That bug has annoyd me for a few weeks.

    ReplyDelete
  44. Happy Holidays, CK, everyone :)

    ReplyDelete
  45. Happy new year, and thanks for your very good job !!

    ReplyDelete
  46. Linux 3.2 is out!

    ReplyDelete