steve@lpi3230.UUCP (Steve Burbeck) (12/19/83)
We run S on two systems: lpi3230 (a Perking Elmer 3230 with 7-Meg running V7 which performs about like a VAX-780 for the price of a 750!) and lpi1155 (a PDP-11/55 with 256K running Xenix). On the PE machine, S is well behaved, but on the 11, it hogs the system whenever it is running batched procedures or long "for" loop commands. Lowering its priority via nice does little to help. As far as I can tell, the problem is that nice has no effect on process creation. The S executive is spawning and activating processes rapidly and swamping the system with swap and disk activity (i.e., iostat shows that it soaks up more than 50% of the available time in system activity to get about 5% user or nice time!) Everyone else's work grinds to a halt, particularly those using ex or vi, and the system shows 30% idle (waiting for disk I/O). I have tamed it for the moment by inserting sleep(2) in main/u/link.c just before the fork and kill call to force S to allow others to use the system. This makes S a good citizen in the sense of not impeding other's use of the system, but seriously degrades the interactive speed of S. Do other sites have similar problems? Does anyone have suggestions for better ways to deal with this problem? (Please spare me suggestions like "don't use it on such a small machine" or comments like "S wasn't meant for such work.") I am intellectually interested in kernel mods but I feel that the proper fix should be to S, not the kernel. S itself could be modified so that it adapted its process activation to current system load rather than blindly sleeping even if no one else is using the system. However I have yet to think of a clean/fast way to get the S executive to decide whether it should sleep or activate a process right away.