site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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... 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? There are a couple of notable exceptions: This leads to a couple of interesting consequences: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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.) 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. - 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. - 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. This email sent to site_archiver@lists.apple.com