Re: -mm merge plans -- anti-fragmentation

On Tue, Jul 10, 2007 at 09:29:45AM -0500, Dave McCracken wrote:
On Tuesday 10 July 2007, Mel Gorman wrote:
 Mel's page allocator work.  Might merge this, but I'm still not hearing
 sufficiently convincing noises from a sufficient number of people over
this.

This is a long on-going story. It bounces between people who say it's not a
complete solution and everything should have the 100% ability to defragment
and the people on the other side that say it goes a long way to solving
their problem. I've cc'd some of the parties that have expressed any
interest in the last year.

I find myself wondering what "sufficiently convincing noises" are. I think we
can all agree that in the current kernel order>0 allocations are a disaster.

Are they? For what the kernel currently uses them for, I don't think
the lower order ones are so bad. Now and again we used to get reports
of atomic order 3 allocation failures with e1000 for example, but a
lot of those were before kswapd would properly asynchronously start
reclaim for atomic and higher order allocations. The odd failure
sometimes catches my eye, but nothing I would call a disaster.

Something like the birthday paradox I guess says that you don't actually
need a large proportion of pages free in order to get higher order
pages free. I think it is something like O(log or sqrt total pages), ie.
similar to what we use for our pages_min sizing, isn't it?


They simply aren't useable once the system fragments. I think we can also
all agree that 100% defragmentation is impossible without rewriting the
kernel to avoid the hard-coded virtual->physical relationship we have now.

With that said, the only remaining question I see is whether we need order>0
allocations. If we do, then Mel's patches are clearly the right thing to do.
They have received a lot of testing (if just by virtue of being in -mm for so
long), and have shown to greatly increase the availability of order>0 pages.

The sheer list of patches lined up behind this set is strong evidence that
there are useful features which depend on a working order>0. When you add in
the existing code that has to struggle with allocation failures or resort to
special pools (ie hugetlbfs), I see a clear vote for the need for this patch.

Really the only patches so far that I think have convincing reasons are
memory unplug and hugepage, and both of those can get a long way by using
a reserve zone (note it isn't entirely reserved, but still available for
things like pagecache). Beyond that, is there a big demand, and do we
want to make this fundamental change in direction in the kernel to
satisfy that demand?


Some object because order>0 will still be able to fail. I point out that
order==0 can also fail, though we go to great lengths to prevent it. Mel's
patches raise the success rate of order>0 to within a few percent of
order==0. All this means is callers will need to decide how to handle the
infrequent failure. This should be true no matter what the order.

So small ones like order-1 and 2 seem reasonably good right now AFAIKS.
If you perhaps want to say start using order-4 pages for slab or
some other kernel memory allocations, then you can run into the situation
where memory gets fragmented such that you have one sixteenth of your
memory actualy used but you can't allocate from any of your slabs because
there are no order-4 pages left. I guess this is a big difference between
order-low failures and order-high.



I strongly vote for merging these patches. Let's get them in mainline where
they can do some good.

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

Relevant Pages

  • Re: -mm merge plans -- anti-fragmentation
    ... For what the kernel currently uses them for, ... reclaim for atomic and higher order allocations. ... Really the only patches so far that I think have convincing reasons are ... there are no order-4 pages left. ...
    (Linux-Kernel)
  • [PATCH 0/11] Avoiding fragmentation with page clustering v27
    ... This is another post of the patches aimed at reducing external ... ability to migrate, not just reclaim. ... Tests show that the kernel is far better at servicing high-order allocations ... memory pressure), large contiguous pages will be freed. ...
    (Linux-Kernel)
  • Re: fragmentation avoidance Re: 2.6.22 -mm merge plans
    ... These patches are the grouping pages by mobility patches. ... categorization of allocations nor a consistent handling of those. ... The choice of mobility marker to use in each case was deliberate (even if I ... reclaim is already implied by the existing categorisations. ...
    (Linux-Kernel)
  • The performance and behaviour of the anti-fragmentation related patches
    ... I've posted up patches that implement the two generally accepted approaches ... physical address space on the vanilla kernel because there is no effort made ... also that the huge page allocations always come from here as well. ... Vanilla Kernel List-base Kernel Zone-base Kernel Combined Kernel ...
    (Linux-Kernel)
  • Re: fragmentation avoidance Re: 2.6.22 -mm merge plans
    ... These patches are the grouping pages by mobility patches. ... there are corner-case machines out ... categorization of allocations nor a consistent handling of those. ... The antifrag patches handle huge page in a special way. ...
    (Linux-Kernel)