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

Rob Landley
2005-11-01T18:24:40Z

On Tuesday 01 November 2005 07:56, Ingo Molnar wrote:
> * Mel Gorman <mel@csn.ul.ie> wrote:
> > The set of patches do fix a lot and make a strong start at addressing
> > the fragmentation problem, just not 100% of the way. [...]
>
> do you have an expectation to be able to solve the 'fragmentation
> problem', all the time, in a 100% way, now or in the future?

Considering anybody can allocate memory and never release it, _any_ 100%
solution is going to require migrating existing pages, regardless of
allocation strategy.

> > So, with this set of patches, how fragmented you get is dependant on
> > the workload and it may still break down and high order allocations
> > will fail. But the current situation is that it will defiantly break
> > down. The fact is that it has been reported that memory hotplug remove
> > works with these patches and doesn't without them. Granted, this is
> > just one feature on a high-end machine, but it is one solid operation
> > we can perform with the patches and cannot without them. [...]
>
> can you always, under any circumstance hot unplug RAM with these patches
> applied? If not, do you have any expectation to reach 100%?

You're asking intentionally leading questions, aren't you? Without on-demand
page migration a given area of physical memory would only ever be free by
sheer coincidence. Less fragmented page allocation doesn't address _where_
the free areas are, it just tries to make them contiguous.

A page migration strategy would have to do less work if there's less
fragmention, and it also allows you to cluster the "difficult" cases (such as
kernel structures that just ain't moving) so you can much more easily
hot-unplug everything else. It also makes larger order allocations easier to
do so drivers needing that can load as modules after boot, and it also means
hugetlb comes a lot closer to general purpose infrastructure rather than a
funky boot-time reservation thing. Plus page prezeroing approaches get to
work on larger chunks, and so on.

But any strategy to demand that "this physical memory range must be freed up
now" will by definition require moving pages...

> Ingo

Rob