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

[Rob Landley]

On Tuesday 01 November 2005 07:56, Ingo Molnar wrote:
> * Mel Gorman <mel@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/