Date: Fri, 16 Apr 1999 05:43:24 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: David Schwartz <davids@webmaster.com> Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <37164F6C.52BEB501@newsguy.com> References: <000001be877d$f5ddd410$021d85d1@whenever.youwant.to>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schwartz wrote: > > > There are two ways of preventing that. One is pre-allocate all > > memory. This is not useful, because the memory available to each > > process ends up being very small. As an experiment, run X Free with > > the pre-zero pages flag set. > > Right. It makes sense only to pre-allocate for those processes that really > need it. Then again, swap is cheap. In some cases, it might really make > sense to make all allocations, demand fills, and copy-on-writes backed by > swap system-wide. But again, I hardly think that's a good general solution. One could get tired of saying this again and again, but I'm not at that point yet. :-) No, it doesn't make sense. Ok, you pre-allocate for some processes. The memory get filled. Then one of the processes using allocation on demand needs more memory. But there is no free memory, so a process gets killed. You are back where you started. Pre-allocation only works if you do it for all processes. And if you do that... Well, run the experiment I mentioned above. > > The second way is to set limits to the memory the processes can use, > > without actually giving up on-demand allocation. FreeBSD supports > > this. Man login.conf(5). > > The problem is, there is no guarantee that I'll be able to use up to my > memory limit. So I don't see how this helps. An overcommit can still result > in a vital process being summarily terminated. Eh? What are talking about? No garantee? See, you have this process that you wants to eat as much memory as possible. If you are not pre-allocating for all processes, you will have to know which process is that. Knowing that, you set a memory limit that leaves you with enough memory to run the rest of the system. Now, this is a limit you *must* find for any solution you try, *except* pre-allocating everything. If you are not pre-allocating everything, you'll have to know how much memory you can use before processes get killed. For example, suppose one uses the "solution" you mention above. Memory gets filled, and then some other process might need more memory, and something get killed. There is no way around this. If you think there is a way around it, think again. If you still think so, try to explain, in details. It is unavoidable. Now, we know processes will get killed. So, next, you want to be able to tell which processes must not get killed. Well, things will get killed as long as memory is needed. So, you need to be running processes for the express purpose of them getting killed, freeing memory so the system can run without anything getting killed. Surprise, what you did is figure out how much free memory is needed for the system to run without anything getting killed. This is equivalent of figuring out how much memory to limit a process to. If you won't/can't find how much memory each process/user can safely use, your only solution is to pre-allocate everything. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37164F6C.52BEB501>