Hi fellow PLUGgers, (Note: this is a post-mortem story for the archives and anyone who uses Ingo Molnar's O(1) performance patches.)
I've been having problems with my OpenOffice.org installation lately. It would be really slow despite the fact that the system was under minimal load, and would take forever to even just paint the first window. I run Sid, Debian's unstable tree, with the OpenOffice.org packages from the Debian OpenOffice group's separate apt repository, so I leave some room for development issues and didn't mind this until I got bored today. After syncing with my apt repositories and doing a dist-upgrade, I decided to investigate the error. It boiled down to noticeable delays during sched_yield() calls as reported by strace. The thing is that a lot of these calls happen while OpenOffice.org is not doing anything, which is the worst place to have delays. I noticed that turning off my distributed.net client solved the sched_yield() delays, which made me realize that the problem only started cropping up when I decided to try out Con Kolivas's performance patch sets, which include Ingo Molnar's O(1) patch. I little browsing pointed me to the schedtool[1] utility by Freek, and then later to the schedutils[2] utility by Robert Love. [1] http://users.odn.de/~odn05207/uhsq/ [2] http://www.tech9.net/rml/schedutils/ schedtool and chbatch from schedutils both do the same thing: they allow you to set the scheduling policy of processes to SCHED_BATCH, which is available in kernels with Ingo Molnar's O(1). Batch or idle scheduling is ideal for long-running non-interactive processes, because they are given longer timeslices by the Kernel. Aside from being good for the backgrounded task (like the distributed.net client in my case, or the SETI@Home client for others), this also allows normal interactive processes to perform much better. >From documentation that came with the schedtool package it seems that with Ingo Molnar's recent O(1) patches, simply setting the nice(1) of a process to a high value wasn't enough. The process's scheduling policy has to be set to SCHED_BATCH as well. From documentation on the chbatch utility it seems that this requirement, or at least the way chbatch works, will change. This is understandable considering that the O(1) and other performance patches are still under development. But for those using them now, it's nice to know that we can push things further (or at least get our desktop apps working as they should). OpenOffice.org works fine now, and it's actually significantly snappier than I remember it to have been when I was using only the vanilla Linux kernel with RML's preempt patches (now I am using Con Kolivas's -ck14 patchset[3] with Andrea Arcangeli's 021124 VM addon). [3] http://kernel.kolivas.net/ To automate the setting to SCHED_BATCH of the distributed.net client process I modified my /etc/init.d/distributed-net script and added the following after the client was loaded: echo -n "Setting distributed.net client scheduling policy: " chbatch `pidof dnetc` This change is verifiable using: $ lsrt PID CLASS PRIORITY CMD 4268 Batch 0 dnetc (lsrt is part of the schedutils package as well) I have further observed using top that anything with a normal scheduling policy than needs the CPU gets it almost immediately, pushing the distributed.net client's CPU usage down, which is how things should really be. Snappier-desktop-apps world, here I come! Wahoo! :) --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
