Date: Wed, 14 Apr 1999 09:34:43 -0400 (EDT) From: Chuck Robey <chuckr@picnic.mat.net> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: current@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <Pine.BSF.4.10.9904140924070.18456-100000@picnic.mat.net> In-Reply-To: <199904141314.JAA24946@kot.ne.mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Apr 1999, Mikhail Teterin wrote: > Poul-Henning Kamp once stated: > > =>Well, this is just an implementation detail, is not it? I don't > =>mean to critisize, or anything, but such thing as "no available > =>memory" is a fairly intuitive... Coming down, again, the malloc > =>should return a usable memory if available and NULL if it's not. > =>Is not this a "natural" semantics? Why can a program die because > =>_another_ program ate up all the rest of the memory? > = > =You know, this strikes me about as productive a discussion as the > [...] > =Very very fundamental to UNIX philosophy is the maxim that it is > =roots responsibility to configure the system right. > > I'm sorry I managed to annoy you. However, a program needs to be > able to know if it can legally ask for more memory, right? And it > is "very fundamental to malloc philosophy", that malloc returns > NULL, when it can not get more memory. Which it apparently does > now on FreeBSD, but only if the program exceeds an artificial > datasize limit... He's not talking about an artificial limit, he's talking about another user making off with all the memory. This sounds very bizarre, how can you possibly ask the system to predict what other user's are going to ask for, in advance? You can't possibly get absolute permissions on malloc'ed area unless you reserve it (and thereby deny the area to other users, when you might only use a small portion of your reserved area yourself) or you restrict other's use of malloc'ed memory. In your request, less users would have their requests satisfied, because if they allocate 100 MB arrays (where they fill only 1KB with data) they would actually be hard-reserving all that 100MB. This doesn't sound like any reasonable policy for general purpose use (although it might very well suit your purposes). These are fundamental design problems (which you have been told already) and the way that FreeBSD chooses to act is arguably a very good one. There is nothing here that violates any fundamental rules, because we are talking about OS wide allocation strategies. If you need guarantees, then you have to buy more memory, more swap, and have less hungry users. > > And if it is not set, it the administrator's problem? May be... > > Should we, perhaps, have it documented in a number of places, > including malloc(3)? > > My other problem with the artificial limits, is that I can only > specify the absolute figures. Besides an ability to use Mb, Gb, > Kb, I'd like to have % there... And, as I mentioned before, an > ability to distribute the class database over NIS... > > -mi > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9904140924070.18456-100000>