Re: malloc under linux

(Note: I used to work with this kind of code in OSes. In vxWorks
we do not have "swap space", much less any issue of overcommit, so
the issue does not arise.)

Eric Sosman <Eric.Sosman@xxxxxxx> writes:
You'll have to ask Steve Summit [why the FAQ does not speak
only of Linux when describing VM systems with overcommit]. Maybe
he's aware of other systems than Linux ...

There are many.

or maybe he didn't want to tar all Linuces simply because some
can be configured this way,

Some are configured that way by default, some are not.

or -- well, you'll have to ask Steve.

Indeed.

In article <87y7ekvwk4.fsf@xxxxxxxxxxxxxxxxx>
Jean-Marc Bourguet <jm@xxxxxxxxxxxx> wrote:
AIX also had the overcommit feature. I got that it is still the case but
not activated by default.

IMHO, the control should not be a global one, but a pre process one.

Unfortunately, this idea -- while attractive -- does not actually
work, at least not in the obvious simple way. If you have a system
in which some processes have managed to overcommit swap space, and
the system encounters a deadlock situation, any number of "well
behaved" processes may wind up in the same trouble. One might
think that the system could simply terminate any or even all
"overcomit-able" processes, but sometimes this kind of termination
requires allocating new resources. (In short, one has to do the
equivalent of malloc() in order to complete the equivalent of
kill(), and it is the malloc() that needs to do the kill() -- hence
the deadlock.)

(It *is* possible to make it work if one sets limits on both the
over- and non-over-commitment levels. The accounting gets fairly
hairy. This also makes various assumptions about the size and
permanence of backing store, i.e., it may become impossible to
remove or shrink a backing-store area. If backing store is to be
shared with regular "disklike" storage, whose size varies depending
on the amount of live data, there are tradeoffs here as well.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
.

Relevant Pages

  • Re: kernel killing processes when out of swap
    ... >> doesn't overcommit any resources. ... A bigger problem is the default stack size of 64 MB per process. ... quickly adds up to a lot of reserved swap space. ... fork() was triggered by an interactive command, ...
    (freebsd-stable)
  • Re: mmap() and address space reservation
    ... Thomas Pornin wrote: ... and the VM allocates the pages when I access them. ... implements overcommit, these are 400 megabytes less in swap space. ...
    (comp.unix.programmer)