Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc

On Wed, 2010-08-25 at 09:20 -0400, Theodore Tso wrote:

On Aug 25, 2010, at 8:52 AM, Peter Zijlstra wrote:

quoted

Also, there's a good reason for disliking (a), its a deadlock scenario,
suppose we need to write out data to get free pages, but the writing out
is blocked on requiring free pages.

There's really nothing the page allocator can do to help you there, its
a situation you have to avoid getting into.

Well, if all of these users start having their own private pools of
emergency memory, I'm not sure that's such a great idea either.

And in some cases, there *is* extra memory.  For example, if the
reason why the page allocator failed is because there isn't enough
memory in the current process's cgroup, maybe it's important enough
that the kernel code might decide to say, "violate the cgroup
constraints --- it's more important that we not bring down the entire
system" than to honor whatever yahoo decided that a particular cgroup
has been set down to something ridiculous like 512mb, when there's
plenty of free physical memory --- but not in that cgroup.

I'm not sure, but I think the cgroup thing doesn't account kernel
allocations, in which case the above problem doesn't exist.

For the cpuset case we punch through the cpuset constraints for kernel
allocations (unless __GFP_HARDWALL).