Messages in this thread | | | Date | Mon, 03 Oct 2005 10:56:57 -0700 | From | "Martin J. Bligh" <> | Subject | Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?) |
| |
> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk patch tries to > allocate more physical contiguous pages for pcp. This would cause some > extra fragmentation at the higher orders but has the potential benefit > of spreading more uniformly across caches. I agree though that for this > scheme to work nicely we should have the capability of draining the pcps > so that higher order requests can be serviced whenever possible.
Unfortunately, I don't think it's that simple. We'll end up taking the higher order elements from the buddy into the caches, and using them all piecemeal - ie fragmenting it all.
If we take lists of 0 order pages from the buddy, we're trying to use whatever dross was left over in there (from a fragmentation point of view) up first, before breaking into the more precious stuff (phys contig bits).
That was why I wrote it that way in the first place - it wasn't accidental ;-)
>From the direction the thread was going in previously, it sounded like you were finding other ways to alleviate the colouring issue you were seeing ... I was hoping that would fix it up enough the desire for higher order allocations would disappear.
To be blunt about it ... making sure that we don't fall over on higher order allocs seems to me to be more important than a bit of variability in benchmark runs ...
M.
- 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/
| |