Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

Mel Gorman
2005-11-01T15:23:07Z

On Tue, 1 Nov 2005, Ingo Molnar wrote:

>
> * Mel Gorman <mel@csn.ul.ie> wrote:
>
> > [...] The full 100% solution would be a large set of far reaching
> > patches that would touch a lot of the memory manager. This would get
> > rejected because the patches should have have arrived piecemeal. These
> > patches are one piece. To reach 100%, other mechanisms are also needed
> > such as;
> >
> > o Page migration to move unreclaimable pages like mlock()ed pages or
> > kernel pages that had fallen back into easy-reclaim areas. A mechanism
> > would also be needed to move things like kernel text. I think the memory
> > hotplug tree has done a lot of work here
> > o Mechanism for taking regions of memory offline. Again, I think the
> > memory hotplug crowd have something for this. If they don't, one of them
> > will chime in.
> > o linear page reclaim that linearly scans a region of memory reclaims or
> > moves all the pages it. I have a proof-of-concept patch that does the
> > linear scan and reclaim but it's currently ugly and depends on this set
> > of patches been applied.
>
> how will the 100% solution handle a simple kmalloc()-ed kernel buffer,
> that is pinned down, and to/from which live pointers may exist? That
> alone can prevent RAM from being removable.
>

It would require the page to have it's virtual->physical mapping changed
in the pagetables for each running process and the master page table. That
would be another step on the road to 100% support.

--
Mel Gorman
Part-time Phd Student Java Applications Developer
University of Limerick IBM Dublin Software Lab