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

David Rientjes
2010-08-25T21:11:46Z

On Wed, 25 Aug 2010, Peter Zijlstra wrote:

> > The cpusets case is actually the easiest to fix: use GFP_ATOMIC.
>
> I don't think that's a valid usage of GFP_ATOMIC, I think we should
> fallback to outside the cpuset for kernel allocations by default.

Cpusets doesn't enforce isolation for only user memory, it's always bound
_all_ allocations that aren't atomic or in irq context (or oom killed
tasks). Allowing slab, for example, to be allocated in other cpusets
could cause them to oom themselves since they are bound by the same memory
isolation policy that all other cpusets are. We'd get random oom
conditions in cpusets only depending on where the slab was allocated at
now fault to those applications themselves, and that's certainly not a
situation we want. The memory controller cgroup also has slab accounting
on their TODO list.

If you think GFP_ATOMIC is inappropriate in these contexts, then they are
by definition blockable. So this seems like a good candidate for using
memory compaction since we're talking only about PAGE_ALLOC_COSTLY_ORDER
and higher allocs, even though it's only currently configurable for
hugepages.

There's still no hard guarantee that the memory will allocatable
(GFP_KERNEL, the compaction, then GFP_ATOMIC could all still fail), but I
don't see how continuously looping the page allocator is possibly supposed
to help in these situations.