A development blog of what Con Kolivas is doing with code at the moment with the emphasis on linux kernel, MuQSS, BFS and -ck.

Monday, 16 January 2012

3.2-ck1

These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but suitable to any commodity hardware workload.

This is an upgrade to BFS 416, trivial bugfixes and a resync from 3.1.0-ck1 . I've changed the versioning to not specify a 3 point release since it usually applies to successive 3 point releases for some time.

## IO Schedulers#CONFIG_IOSCHED_NOOP=yCONFIG_IOSCHED_DEADLINE=yCONFIG_IOSCHED_CFQ=yCONFIG_IOSCHED_BFQ=y# CONFIG_DEFAULT_DEADLINE is not set# CONFIG_DEFAULT_CFQ is not setCONFIG_DEFAULT_BFQ=y# CONFIG_DEFAULT_NOOP is not setCONFIG_DEFAULT_IOSCHED="bfq"

Chromium showing an Aljazeera live newsTV. Left the points and double crosses shows the intel core2-duo frequences. After five frequences mesurement there is an insertion of the two topmost top output:

They contiously go down. From nearly 60 percent to 38. Also firefox.I don't know if these two self adjusting applications are programed to do it. Or if your BFS scheduler adjusts throughput.

Thank you for the 3.2 release. It's working very well for me. How was the game? How many hours did it take for you to complete it?

By the way, I made a new blog about tips and tweaks for Linux. I'm going to write an article soon about how to patch and recompile the kernel with ck and bfq on dpkg/apt based systems. You can find my blog here: http://tux9656.blogspot.com/

This indeed does reproduce one aspect of BFS and behaves more like a global queue, but from a completely different approach. This inherently should lead to lower latencies on SMP machines, but may also decrease throughput substantially if poorly done. It does not, however, address the issue of how to order tasks such that the interactive ones go first based on pure fairness, and leaves that aspect still the CFS run/sleep algorithm. So it makes for a halfway point between CFS and BFS. It's hard to know if it's the best of both worlds... or the worst without testing :)

Used BFS 2.6 kernel for a while on Ubuntu 10.10 -> switched to Fedora since 11.04, but used stock kernel, until Cinnamon came out to replace Gnome Shell, which led me to go back to Ubuntu 11.10 -> came back and checked out BFS, used the whole afternoon to build the kernel, now everything's back to normal. The responsiveness improvements are just there. Totally worth it.

- I get a gentoo-sources kernel and a ck-sources (gentoo-sources + ck patchset) kernel with all common options set identically. - I moved both from 2.6.38 version to 3.2.1 keeping all common options identical and setting all new options carefully. - My system is based on an Intel CoreII duo + 4Gb RAM.

On my system running its typical load, I noticed a drop in performances from ck-sources 2.6.38 to ck-sources 3.2.1, drop that I cannot objectively quantify.

I generally use the deadline scheduler and specific mount options but I tried here on an ext4 with default mount options and the noop scheduler.BTW, I always keep the rr_interval to its default value of 6.

The results for write and rewrite tests show that :

- Under a 2.6.38 + BFS, the throughput is approximately identical to a 2.6.38 + CFS for a number of processes less or equal to 4. With more than 4 processes, the throughput is divided by 4.Normal! well, at least, this is what I am used to.

- Under a 3.2.1 + BFS, the throughput is a fourth of a 3.2.1 + CFS irrespective of the number of processes.

I know that threaded IO has always been a weakness of BFS but my typical load never creates situations in which more than 4 processes are competing for writing on the same IO ressource, so I generally do not care.

- Did you notice the same kind of performance drop ? - Did I do something wrong with my configuration ? - Is this benchmark meaningless ? - I read about the modifications made on ext4 in 3.2.1 but did not realize that they would have any impact here. Am I wrong ?

Yes that's intentional. I/O throughput happens at the expense of CPU interactivity so the -ck patchset is continually trying to reign in the I/O throughput to improve interactivity. If you care more about keeping your I/O throughput then use just the BFS patch and not the full -ck patchset.

=When you said throughput, I'm pretty sure you mean I/O throughput since the CPU throughput is unchanged. I said it was intentional. It's in the -ck patches and due to changes to the VM and I/O scheduler between that older kernel and the current one that make -ck more effective at reducing throughput. The patches in -ck CONSCIOUSLY REDUCE I/O THROUGHPUT. So the patches are both designed to do that, and are successfully achieving that. So once again, if I/O throughput is important to you, you should not be using the -ck patchset. rr_interval has NOTHING to do with I/O throughput. Now if you're not talking about I/O throughput, then please explain further.

Yes ! I was talking about I/O throughput.Thanks for clarifying the drop from 2.6.38 to 3.2.1As for the impact of the rr_interval, I had noticed a slight difference in I/O throughput when increasing from 6 to 300, to the expense of the latency. But it definitely appears that I had misunderstood your FAQ. I apologize for this.

I am not that much concerned by I/O throughput and much more in the possibility to globally achieve my work in about 85% of the time they need under a non ck-patched kernel.I see Sysbench thread test achieved in 60% of the time needed on a 3.2.1 non patched kernel.The ratio was of 77% with 2.6.38

Thank you again for knowing that everyone does not get google's architectures and needs...

So... reading through your replies, i should only use my kernel with one lonely BFS-patch?For my ancient system, I/O througput is most probably the main bottleneck (except for AGP4x limits that are not on your bill)?

It's not that simple. Your disk I/O may well be the slowest component in your system, but if you do things to increase the I/O it almost always leads to other slowdowns, usually of the perceptible interactivity type. So you may speed up writing a big file but then your desktop may come to a standstill while you wait for it to write that file. That's why I'm forever doing things in -ck that make I/O slower rather than faster.

Thank you very much for your explanations!But if I look at my overlapping /dev/shm that sometimes goes from RAM to swap (and maybe kicks other desktop-related things to disk as well) there should'nt be "double brakes" or triple or even...: for disk I/O, swap related I/O (mm-idleprio_prio-1.patch and mm-kswapd_inherit_prio-1.patch.orig as I read them), and some possible BUGs that make shm <-> RAM <-> swap transitions and vice versa so CPU/Bridge intense.I still cannot reflect, why the removal of my previously mentionned patches from complete CK makes such a difference in desktop's responsiveness.This is no critcism of your patchset related work, please read it as another spot to point your next optimization work to.I seem to be the last one running an uptodate kernel with CK on an over 12 years old machine, that seems to reveal kernel bottlenecks more easily. :-(

O.k., yes, several times now. ;-) I've realized that message, finally.Are there any shareable insights on whether the autoiso-xorg.patch from bfs-313 days and or the schedtool approach are of benefit any more? (I'd always compiled it in. And I was used to 'enhance' a blocking application to finish earlier via schedtool -I `pidofproc app` from time to time.)

I never recommended anyone use the autoiso patch. That's why it was never included in any -ck release. The potential for it blocking audio which is even more important than xorg is why I decided against it.

One or both of the following patches add an overall plus to the personal(!) feeling of a quickly responding desktop on my vintage machine: 04.mm-drop_swap_cache_aggressively.patch 06.mm-background_scan.patchwith BFS-416 and current bfq and kernel 3.2.9 (openSUSE).

So, that's mainly the same setup as posted on 2012-03-03, with reverting from the ck-patch: 09.mm-decrease_default_dirty_ratio-1.patch 08.mm-lru_cache_add_lru_tail-2.patch 07.mm-idleprio_prio-1.patch 05.mm-kswapd_inherit_prio-1.patch.orig 02.mm-minimal_swappiness.patch

Too poor: This comment only reflects subjective recognitions with my previously posted testing and daily workflows.But maybe there's some usefulness for some people so that you don't abandon all mm related patches.

Sorry, English isn't mine either.My system feels like responding better to desktop input and hardware throughput, e.g. playing videos additionally to other actions. So, that's nothing about "My system is faster." it's about "My system interacts faster with me." From my point of view that has more value than any benchmarked numbers. But it's only subjective, and not reproducible from one to another.[Manuel Krause]

@CK:There's no real advantage if I set Xorg to SCHED_NORMAL (unlike in the autoiso.patch) as it affects the input system as well. Or setting pulseaudio to SCHED_ISO or both. Pulseaudio is running @ NICE -11 (default on here). One of both always suffers somehow when CPU/Gfx/IO are under heavy load. I assume I'd need to experiment with the NICE levels to find out what helps more. But that's quite a boring test work ;-)[Manuel Krause]

Of course there is no "advantage" to setting Xorg to SCHED_NORMAL since that's... doing nothing. The issue is in YOUR desktop YOU are running pulseaudio and at nice -11. But that is not everyone, and I need a kernel that works best for everyone. If you find the patch helps you, go right ahead, but I will not include that patch by default.

@ck:Maybe... I am really boring you with my comments/questions? Your replies make me feel like that. If I would not want to get the best experience from my existing system, what I supposed to be your goal, too, I've never had asked.

@anonymous coward:Most recent releases of pulseaudio can manage multiple sources of audio like video + skype + system notifications that alsa was never capable of. Maybe... you like to give it a new try![Manuel Krause]

For the git lover. I set up a git repository to trace the linux-stable git tree and add some of my favorite patch sets. Of course, bfs/ck patch set is the major party of them. Current, bfs/ck, bfs and phc-intel are patch sets I am tracing in this reposiroty.

Branches, there will be a branch to trace each kind of patch, for example, linux-3.2.y-bfs to trace the BFS patch.Tags, once a stable kernel released and the patch apply successfully and build out, a signed tag will be added, such like v3.2.9-ck1 and so on.Test, a kernel build test will be run to test the patch with kernel release before test. I just use the -gc one by myself, so I have no promises all of them runs ok.Merge strategy, when a new stable kernel version bumped, this repository will be sync-up with the upstream repo( linux-stable.git ). -bfs,-bfq and phc-intel branch will be rebased to the new stable tag, after build test, a tag with patch name sub-fix will be signed. -ck branch will be rebased with the new created -bfs tag, after build test then signed the -ck tag. Finally, -gc branch will be rebased with phc-intel, -ck and -bfq branch, build then signed the tag.To use, the git way, clone the repository, checkout the tag you want and build you kernel. Tarball way, visit the download tab, click on the download link of given tarball format with the tag you want.