NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Writing is interesting (Score:1)
Novices often suspect Unix priorities don't really do anything - setting an interactive session to the lowest (maximum) priority doesn't actually make it more responsive. While such novices eventually learn why this happens and come to accept it, I suggest this behavior is wrong and should not be accepted.
Virtually all systems have excellent interactive performance when running only interactive applications out of RAM, but fewer maintain good interactive performance while running both batch applications and interactive applications. Unix performs extremely poorly in this scenario. Running Mozilla for a week and running an xterm at the same time tickles just as well as traditional batch applications along side interactive sessions.
The schedular favors processes that don't attempt to use the maximum amount of CPU available to them - however, these processes are almost never runnable because the virtual memory system recgonizes them as not recently having used their pages if they idle for even a fraction of a second, and the VM system swaps them out to make room for processes actually running at a lower priority. Worse, when an interactive application does attempt to use some CPU, its pages are swapped out almost as fast as they are swapped in - pages are litteraly go cold and are swapped back out while it waits for other pages to be swapped in. This manifests itself as applications taking an excessively long time for their size to page back in to memory.
In summary, the algorithms employed in Unix are not only excessively simplistic but actually clash with each other and perform pathologically badly.
-scott
Reply to This