Messages in this thread | | | Date | Fri, 27 Jan 2006 02:51:26 -0800 | From | Paul Jackson <> | Subject | Re: [patch 3/9] mempool - Make mempools NUMA aware |
| |
Matthew wrote: > I'm glad we're on the same page now. :) And yes, adding four "duplicate" > *_mempool allocators was not my first choice, but I couldn't easily see a > better way.
I hope the following comments aren't too far off target.
I too am inclined to prefer the __GFP_CRITICAL approach over this. That or Andrea's suggestion, which except for a free hook, was entirely outside of the page_alloc.c code paths. Or Alan's suggested revival of the old code to drop non-critical network patches in duress.
I am tempted to think you've taken an approach that raised some substantial looking issues:
* how to tell the system when to use the emergency pool * this doesn't really solve the problem (network can still starve) * it wastes memory most of the time * it doesn't really improve on GFP_ATOMIC
and just added another substantial looking issue:
* it entwines another thread of complexity and performance costs into the important memory allocation code path.
Progress in the wrong direction ;).
> With large machines, especially as > those large machines' workloads are more and more likely to be partitioned > with something like cpusets, you want to be able to specify where you want > your reserve pool to come from.
Cpusets is about performance, not correctness. Anytime I get cornered in the cpuset code, I prefer violating the cpuset containment, over serious system failure.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |