From owner-freebsd-current Wed Apr 14 7:27:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 08A3515268 for ; Wed, 14 Apr 1999 07:27:18 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA09018; Wed, 14 Apr 1999 23:24:50 +0900 (JST) Message-ID: <3714A4C2.96BE6188@newsguy.com> Date: Wed, 14 Apr 1999 23:22:58 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Mikhail Teterin Cc: current@FreeBSD.ORG Subject: Re: swap-related problems References: <199904141353.JAA25377@kot.ne.mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Teterin wrote: > > All I want is that a program gets NULL from malloc if there is no memory > available. I find that to be a very fundamental thing about malloc. > > In response, me and others are told at different times: > > . there is no such thing as "no memory available" (!!!) > . you can get that behaviour by limiting the user's maximum > datasize > . this wouldn't work without dumping the overcommit strategy, > which would demand more memory and will slow things down > . be a better sysadmin > . get more memory and swap > . this discussion is annoying and fruitless (!!!) > > I find this responses unacceptable, or only partially acceptable... There is two ways you can alloc memory: on-demand or pre-allocated. Most Unixes out there choose on-demand because it let you do more with less. A *lot* more. The only way to do what you want is to pre-allocate. Alas, suppose you set pre-allocation for your eat-all-memory application. You application starts, eat all memory and stabilizes. Then you move the mouse in X Free causing previously allocated memory to be accessed. There is no memory available, so the largest process is killed. That would be your eat-all-memory application. What some of us have been telling you is that there is no easy way out of this. Some have suggested "don't kill this process" solutions. This is a poor solution, because it requires much more sysadmin tweaking than limiting user's maximum datasize. If you pre-allocate all memory you'll find out you have much less memory available for you. MUCH less. Yeah, a pre-allocate all memory general system flag would be interesting, but mostly because we could then say "turn this on and see how you suddenly don't have memory to even start X Free". Or, in other words, if you set a maximum datasize for your application, you can allocate MUCH more memory to that application than if our allocation strategy was pre-allocate. Do you have a solution? We don't. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message