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!
Thanks ck! Bug fixes are not bad, it make the code more stable.
ReplyDelete:) blah blah bug fix :) and go to build new CK to kernel.
ReplyDeleteCK - 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[Ralph Ulrich]
ReplyDeleteYeah, 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).
Here are the data:
ReplyDeletehttp://s10.postimage.org/ewhwamyhz/compare.png
Is it possible to create 415 for 3.0.9 ?
ReplyDelete415 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[Ralph Ulrich]
ReplyDeleteRecently 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 ....
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[Ralph Ulrich]
ReplyDeleteI 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 ?
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:
ReplyDeletePORTAGE_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.
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.
ReplyDeleteThis is what I do: in my .profile and .bashrc I added
ReplyDeleteif [ "$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. ;)
Hey CK,
ReplyDeletejust 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
Hi CK,
ReplyDeletemy 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)
CK,
ReplyDeleteI 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.
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.
ReplyDeleteHi CK,
ReplyDeletecan you please comment on my posting from 2011-11-24? Or has it been 'too specific'?
Best regards,
Manuel Krause
@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@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.
ReplyDeleteDecreasing 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
I didn't say it was logical behaviour. I was just explaining what is likely happening, and I'd say it sucks too.
ReplyDeleteHi 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[Ralph Ulrich]
ReplyDeleteThere 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?
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[Ralph Ulrich]Systemd is a service-management utility, BFS a scheduler. What features do you talk about?
ReplyDeleteI do use an Linux-3.1.5 BFS patched kernel on a Debian-unstable with systemd as init in this moment of writing ...
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[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@CK: Many thanks for your answer!
ReplyDeleteCan 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]
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[Ralph Ulrich] Also regarding the mm mv thing (I am not a kernel hacker):
ReplyDeleteI 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?
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[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 ...
ReplyDeleteInteresting patch (IO-less dirty throttling v12), thanks for the link!
ReplyDelete@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.
ReplyDeleteThey 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
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@CK: Thanks for informing me about these facts.
ReplyDeleteMy "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
Yes, according to http://lwn.net/Articles/465537/ it has been merged.
ReplyDeleteI 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 ;-)
ReplyDeleteManuel Krause
Anyways, for running 3.1.* kernels, it's a worthy trial.
ReplyDeleteWhether 3.2 comes @ X-Mas with it or without,
Many thanks to Con!
Manuel Krause
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— Recently I've noticed some really insane values in sys part of timing: http://poige.livejournal.com/520776.html
ReplyDeleteYep 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.
ReplyDeletePerhaps someone knowledgeable enough here could look into it?
ReplyDeleteHope you can find the time to release a 3.2-based BFS though :)
That bug has annoyd me for a few weeks.
ReplyDeleteHappy Holidays, CK, everyone :)
ReplyDeleteHappy new year, and thanks for your very good job !!
ReplyDeleteLinux 3.2 is out!
ReplyDelete