Messages in this thread |  | | | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 | | From | Dave Hansen <> | | Date | Tue, 01 Nov 2005 15:49:15 +0100 |
| |
On Tue, 2005-11-01 at 15:29 +0100, Ingo Molnar wrote: > * Dave Hansen <haveblue@us.ibm.com> wrote: > > > can you always, under any circumstance hot unplug RAM with these patches > > > applied? If not, do you have any expectation to reach 100%? > > > > With these patches, no. There are currently some very nice, > > pathological workloads which will still cause fragmentation. But, in > > the interest of incremental feature introduction, I think they're a > > fine first step. We can effectively reach toward a more comprehensive > > solution on top of these patches. > > > > Reaching truly 100% will require some other changes such as being able > > to virtually remap things like kernel text. > > then we need to see that 100% solution first - at least in terms of > conceptual steps.
I don't think saying "truly 100%" really even makes sense. There will always be restrictions of some kind. For instance, with a 10MB kernel image, should you be able to shrink the memory in the system below 10MB? ;)
There is also no precedent in existing UNIXes for a 100% solution. From http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/dlpar.htm , a seemingly arbitrary restriction:
A memory region that contains a large page cannot be removed.
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.
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.
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.
-- Dave
- 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/
|  |