On Tue, Oct 09, 2001 at 05:20:44PM -0500, Mike Hicks wrote: > Out of curiosity, what would be good ways to handle the problem? I think you have two choices: build the kernel so that it saves them, or so that it avoids the condition in the first place. A lot of it would have to do with the scheduling algorithm, and how the OS defines a process. I know that Unix (including Linux) is geared to a lot more small, light processes, whereas a VMS process is a lot more intensive. Unix is a lot better at running things like GUI systems, where you have a lot of little processes. VMS is more efficient at throughput (I/O and all other things being equal.) How you decide which processes to freeze or kill would have to do with how the system prioritized them in the first place. Another approach would be to swap out the hog, finish off as many of the small processes as possible, and try and make room for the big one. The thing is what processes depend on other processes. Again, in VMS a process is more self-contained, whereas Unices have more of a rats nest of dependencies. So it's really a fundamental level decision. > I know > that the Linux kernel will kill processes in these sorts of conditions in > an attempt to free up memory. I'm not sure how the kernel picks a process > to kill. Yeah, you'd have to get down into the scheduler and prioritizing. > Now that I think about it, the kernel has probably killed my X server a > few times, explaining why my system has occasionally appeared to be > unresponsive at the console. Well, that could be coincidence, or could be conscious. It would be a reasonable choice to say "if the system starts to bog, kill the Xserver so that data in running apps can be preserved." I don't know if I have that much time for reading source these days, though. -- I used to like HP before computers, and once I even liked Compaq, but I liked DEC better than HP and Compaq put together.