So I've resynced all the 2.6.36-rc7-ck1 patches, and added a couple of things.
Firstly, I added a tiny patch which decreases the default dirty_ratio in the vm from 20 to 5. Here is the changelog in the patch:
The default dirty ratio is chosen to be a compromise between throughput and
overall system latency. On a desktop, if an application writes to disk a lot,
that application should be the one to slow down rather than the desktop as a
whole. At higher dirty ratio settings, an application could write a lot to
disk and then happily use lots of CPU time after that while the rest of the
system is busy waiting on that naughty application's disk writes to complete
before anything else happening.
Lower ratios mean that applications that do a lot of disk writes end up
being responsible for their own actions and they're the ones that slow down
rather than the system in general.
This does decrease overall write throughput slightly, but to the benefit of
the latency of the system as a whole.
The only other changes are to fold in the build fixes into BFS, fix minor typos in the documentation of the BFS 357 patch, and the add the bfs357-penalise_fork_depth.patch and bfs357-group_thread_accounting.patch patches as separate entities, but DISABLED by default. The effect of these patches has been discussed at great length on this blog before. See the tunables in /proc/sys/kernel to enable them. I'm pretty sure these patches will be dropped for 2.6.36-ck1 final due to the handful of regressions seen to date.
As per last time, the patches themselves are sneakily hidden within .lrz archives which means you'll have to suffer the pain of installing my lrzip application to use them. The patches are available in here: 2.6.36 prerelease patches
Disabled by default, ok, but please don't drop the new patches from ck1-final. As for mplayer and gnome applets failing to initialize with group_thread_accounting, I don't use them anyway :)
ReplyDeleteYou like them? Disabled they add a small amount of overhead but don't change the behaviour of the default so it won't be too painful to add. However, why is it so hard to nice your compiles? It has exactly the same effect, and there is precisely ZERO point to using more jobs than CPUs. I'm really struggling with why people love this so much. This goes back to why I hated heuristics so much in the first place that made me write a new scheduler.
ReplyDeleteFor people who actually have a use for it, a kernel configuration option for those two patches would probably be more appropriate. Not sure if the patches can be integrated that way though.
ReplyDeleteWell ok, I guess we can nice our compiles. However perhaps the patch could be released separately so that those who want it can add the extra code to bfs using Patch.
ReplyDeletethanks ck for the inspiration!
ReplyDeleteI heard rc doesn't stand for release candidate.
ReplyDelete