Re: malloc returning NULL, was Panic in OSMalloc??
Re: malloc returning NULL, was Panic in OSMalloc??
- Subject: Re: malloc returning NULL, was Panic in OSMalloc??
- From: Michael Smith <email@hidden>
- Date: Fri, 11 Jan 2008 09:03:06 -0800
On Jan 11, 2008, at 8:48 AM, Rick Macklem wrote:
I just responded to the "Panic in OSMalloc??" thread and then realized
that "what to do when malloc returns NULL" is an interesting question,
for which I don't have a good answer...
When malloc returns NULL, it makes sense that the system is in some
sense
constipated. To know how much, you'd need to know how the allocators
are implemented and what they are being used for. (Beyond what I know
about MacOS X.)
It seems to me that a non-blocking malloc returning NULL could just
indicate that the allocator has hit a transient high water mark and
retrying the allocation allowing blocking would make sense?
Whether or not retrying a blocking malloc when it returns NULL is a
good
plan is more questionable. It seems to me that, for this case, the
system
may be pretty badly constipated and returning ENOMEM may be
preferable?
My NFS code was written way back when, when the BSD kernel malloc
never
failed for the blocking case, so I didn't have to deal with this.
I'm hoping others will have comments? rick
This is actually a great topic. I have a deal of input, as I was one
of the instigators of the original M_NOWAIT cleanup in FreeBSD, and we
hashed this out fairly well at the time.
At most points in the kernel when you're allocating memory, you're
doing work for someone else. What you can do about failures largely
depends on how that client is going to deal with a transient failure.
Most ultimate clients are willing to block arbitrarily long, but are
not prepared to deal with transient or retryable failures. In the
common case, this means that you're better off waiting in malloc. You
should not be trying to second-guess the state of the system; you
should be counting on the system to do something sensible and
servicing your client according to their expectations.
There are a couple of notable exceptions:
- You may be in a state where you cannot block. Typically, I'd say
that if you need to allocate but you can't block, you need to go back
and fix your design because it's busted, but there are always
exceptions. To make this work, you have to have a fallback strategy
that isn't going to upset your client.
- It is sometimes the case that if you can make an allocation on the
nonblocking path you can achieve an optimisation and avoid invoking a
slower path to do the work.
- You may be holding a lot of memory already. If you're in a state
where you believe that you may be contributing to or causing kernel
map starvation, you might want to implement your allocations in a more
tentative fashion. This really still falls into the "busted"
category; if you know you're likely to be starving the kernel out, you
should redesign rather than mitigate, but again there are always
exceptions. In this case, your best bet is likely to be to backoff
and retry.
This leads to a couple of interesting consequences:
- The system needs to have strategies in place for making forward
progress when normal allocations are failing/blocking.
- Subsystems that use allocated memory may be better off requiring
that their clients do the allocation according to their constraints,
rather than trying to offer blocking/nonblocking versions of their
interfaces.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden