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

Ingo Molnar
2005-11-01T14:46:14Z

* 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.

Ingo