Date: Wed, 14 Jul 1999 15:20:19 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <v04011705b3b290d4fe23@[128.113.24.47]> In-Reply-To: <378CCB7D.AD8BC57B@newsguy.com> References: <199907132346.TAA13780@bikini.ihack.net> <v04011702b3b275648c0f@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:40 AM +0900 7/15/99, Daniel C. Sobral wrote: >Garance A Drosihn wrote: >> >> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: >> > In which case the program that consumed all memory will be killed. >> > The program killed is +NOT+ the one demanding memory, it's the one >> > with most of it. >> >> But that isn't always the best process to have killed off... > >Sure it is. :-) Let's see... > >> One of my main freebsd machines is mainly here to run one >> process, which is a pretty good-sized process (>40meg). If >> I did get into a memory-shortage problem, I do *not* want >> that process killed, I'd want some other processes killed. > > Just size your swap so that it becomes unlikely that you run out of > memory before a process exceeds 40Mb. > > And I mean it. For the moment I'll pretend that you honestly think that is an answer, and I'll note that the very same machine may have well over 100 processes each of which takes 1-2 meg of memory. If the machine hits a really-out-of-memory error, I would be much much happier to see all 100+ of those processes killed, at once, than the one 40-meg process. Now tell me how I fix my swap under those circumstances. If the answer is "buy infinite memory (ram or disk)", then we don't need any overcommit policy in the first place. Note that the problem might be that these 100 processes start taking up 5 or 10 meg than the 2 meg I'm used to. > I once described in excruciatingly painful details why a number of > other techniques would end up being more difficult to implement than > the above. If you really want to know, check the archives. The very, > *very* least anyone with *real* interest in this thread can do is > read the archives on this subject for the past six or seven years. I once participated in a discussion on this very list where people would discuss SIGDANGER with some degree of intelligence, instead of offhand smart-aleck remarks. That discussion (as I remember) ended with the conclusion that "SIGDANGER can be useful, but there's a fair amount of work to do first". My comment was actually meant as a follow-up to that earlier discussion, just to see if anything had happened to get us closer to this. (as I remember, the first hurdle was something to do with supporting more signal-types). I didn't mean to be casting asperisions on the general idea of overcommitting, or whatever it is that has your shorts all tied up in a knot. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011705b3b290d4fe23>