On Wed, 25 Aug 2010, Peter Zijlstra wrote: > I'm not sure, but I think the cgroup thing doesn't account kernel > allocations, in which case the above problem doesn't exist. > Right, the only cgroup that does is cpusets because it binds the memory allocations to a set of nodes. > For the cpuset case we punch through the cpuset constraints for kernel > allocations (unless __GFP_HARDWALL). > __GFP_HARDWALL doesn't mean that the allocation won't be constrained, this is a common misconception. __GFP_HARDWALL only prevents us from looking at our cpuset.mem_exclusive flag and checking our nearest common ancestor cpuset if we can block. The cpusets case is actually the easiest to fix: use GFP_ATOMIC. GFP_ATOMIC allocations aren't bound by any cpuset and, in the general case, can allocate below the min watermark because of ALLOC_HARD | ALLOC_HARDER in the page allocator which creates the notion of "memory reserves" available to these tasks. Then, success really depends on the setting of the watermarks instead. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
