Date: Wed, 12 Mar 2003 16:51:15 -0800 From: David Schultz <das@FreeBSD.org> To: Mike Silbersack <silby@silby.com> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c Message-ID: <20030313005115.GA11794@HAL9000.homeunix.com> In-Reply-To: <20030312175458.J32334@odysseus.silby.com> References: <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030312175458.J32334@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Mike Silbersack <silby@silby.com>: > Have you tested this well? I ask only because the last time I played > around with the swap killing code, I noticed that it was very fragile. > More specifically, the kill signal isn't actually read and the kill > performed until the process is swapped in and ran. Hence, with a lot of > processes, that could take longer than expected. If you have time, you > might consider looking around to see if the kill can be made more > immediate. With KSE, all of the threads in the process are made runnable. I assume this is to get them to all exit the kernel as fast as possible so the process can die, although there may be a better solution. Still, it shouldn't be a big problem. A real problem is that a swapped out process' uarea has to be paged back in, even when no memory is available. I don't think there's an easy way around that, given that you need the uarea and kernel stack to handle the signal. But at least it's just the uarea; the rest of the process doesn't need to be paged back in. It may be partly for this reason that the pageout daemon starts killing things before memory is completely exhausted. In any case, with this patch I haven't been able to reproduce any problems under fairly heavy load. I have noticed that the pageout daemon sometimes picks a bad process to kill (in my case, sshd on a remote testing box) when the monster process that is consuming all of memory is locked. Unfortunately, the pagedaemon shouldn't block in a low swap situation to avoid deadlocks. A partial solution that might be a little bit more accurate would be to find some way to get at pm_stats.resident_count without requiring any locks, and just estimate swap usage for locked processes. Again, I don't know if that's worthwhile. I believe Juli is working on a way to designate certain processes as unkillable by the pageout daemon, so people running postgres on a busy system, for instance, are not unpleasantly surprised when the pageout daemon runs out of breathing room and decides that postmaster is the biggest process. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030313005115.GA11794>