Re: what is expected malloc behavior re. limits/insufficient resources?
Re: what is expected malloc behavior re. limits/insufficient resources?
- Subject: Re: what is expected malloc behavior re. limits/insufficient resources?
- From: Terry Lambert <email@hidden>
- Date: Fri, 26 Dec 2008 01:43:30 -0800
On Dec 25, 2008, at 4:58 PM, Jack Howarth <email@hidden>
wrote:
In a situation where the malloc request:
is < MALLOC_ABSOLUTE_MAX_SIZE
but > [total RAM + total free swap partition space]
or > ulimit -v , or ulimit -d (regardless of soft/hard)
it seems that malloc() returns a non-NULL pointer (i.e. without
error).
It returns a pointer into a page mapping in the process virtual
address space. No physical pages are allocated until you touch
them. This can exceed total RAM plus swap
+because of memory overcommit, which has pretty much been SOP on
unix since the DEC VAX version introduced virtual memory.
Terry,
Why does linux treat this situation as a malloc error? Does UNIX
conformance imply acceptance
of situations like this that have been addressed by the linux
community?
Jack
(NB: I can talk about what administrative limits mean in the context
of UNIX conformance, if you want, but that doesn't seem to be the
issue you want to talk about here)
Assuming, for the sake of your argument, things work the way you have
indicated on all Linux distributions with every malloc()
implementation, I wouldn't so much say Linux has "addressed" the
"situation" as that they've made different design decisions than us
based on implementation details and how they expect their product to
be used.
I've previously pointed out one difference in implementation detail
that bears strongly on this particular issue, which is static
allocation of swap partition space on Linux systems. Given a static
bounding on that, if they ignore competing processes, they can make
decisions based on how much swap will be available in the future, no
matter what else happens; we can't, since creating/extending (non-
swap) files detracts from the actual amount for us. On the other hand,
on Linux, if you run out of swap because you have two processes that
unwittingly cooperate to run you out, game over. If the same thing
happens on Mac OS X (or Windows), and there's free disk space
available, more space is allocated automatically, and you merrily chug
along. Unless you have badly broken application code or an already
full disk, that's going to be a much better user experience than "time
to repartition your disk and reinstall your OS".
If you think one of Linux's decisions is wrong, you can give the
maintainers of whatever distribution code that implements things a
different way, and Alan Cox or one of the other gatekeepers can make a
decision to accept or reject your code.
If you have the same problem with Mac OS X, you can do the same thing
via a problem report (or even file the report without including code;
you don't have to be a computer programmer to report what you think is
a problem).
At this point, I suggest you file a problem report; please include
your use case that demonstrates why it's a problem, since that will
give the engineer it lands on more ammunition to make the change you
want if they can say it's a demonstrable customer-facing issue.
Cheers,
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden