Messages in this thread | | | Date | Wed, 02 Nov 2005 11:51:24 +1100 | From | Nick Piggin <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
Dave Hansen wrote:
> What the fragmentation patches _can_ give us is the ability to have 100% > success in removing certain areas: the "user-reclaimable" areas > referenced in the patch. This gives a customer at least the ability to > plan for how dynamically reconfigurable a system should be. >
But the "user-reclaimable" areas can still be taken over by other areas which become fragmented.
That's like saying we can already guarantee 100% success in removing areas that are unfragmented and free, or freeable.
> After these patches, the next logical steps are to increase the > knowledge that the slabs have about fragmentation, and to teach some of > the shrinkers about fragmentation. >
I don't like all this work and complexity and overheads going into a partial solution.
Look: if you have to guarantee memory can be shrunk, set aside a zone for it (that only fills with user reclaimable areas). This is better than the current frag patches because it will give you the 100% guarantee that you need (provided we have page migration to move mlocked pages).
If you don't need a guarantee, then our current, simple system does the job perfectly.
> After that, we'll need some kind of virtual remapping, breaking the 1:1 > kernel virtual mapping, so that the most problematic pages can be > remapped. These pages would retain their virtual address, but getting a > new physical. However, this is quite far down the road and will require > some serious evaluation because it impacts how normal devices are able > to to DMA. The ppc64 proprietary hypervisor has features to work around > these issues, and any new hypervisors wishing to support partition > memory hotplug would likely have to follow suit. >
I would more like to see something like this happen (provided it was nicely abstracted away and could be CONFIGed out for the 99.999% of users who don't need the overhead or complexity).
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |