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

[Dave Hansen]

On Tue, 2005-11-01 at 14:56 +0100, 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?

In a word, yes.

The current allocator has no design for measuring or reducing
fragmentation.  These patches provide the framework for at least
measuring fragmentation.

The patches can not do anything magical and there will be a point where
the system has to make a choice: fragment, or fail an allocation when
there _is_ free memory.

These patches take us in a direction where we are capable of making such
a decision.

> > 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%?

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.

-- Dave

-
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/