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

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

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 BFQeach of them with boot-time swappiness/dirty_ratio settings.

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.

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.

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

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

[Ralph Ulrich]There is some discussion athttps://wiki.archlinux.org/index.php/Talk:Systemdcited 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.

[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?

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.

[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/

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

@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

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.

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