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

["Martin J. Bligh" <mbligh@mbligh.org>]

>> with CONFIG_4KSTACKS :)
> 
> 2-page allocations are _not_ a problem.
> 
> Especially not for fork()/clone(). If you don't even have 2-page 
> contiguous areas, you are doing something _wrong_, or you're so low on 
> memory that there's no point in forking any more. 

64 bit platforms need kernel stacks > 8K, it seems.

> Don't confuse "fragmentation" with "perfectly spread out page 
> allocations". 
> 
> Fragmentation means that it gets _exponentially_ more unlikely that you 
> can allocate big contiguous areas. But contiguous areas of order 1 are 
> very very likely indeed. It's only the _big_ areas that aren't going to 
> happen.
> 
> This is why fragmentation avoidance has always been totally useless. It is
>  - only useful for big areas
>  - very hard for big areas
> 
> (Corollary: when it's easy and possible, it's not useful).
> 
> Don't do it. We've never done it, and we've been fine. Claiming that 
> fork() is a reason to do fragmentation avoidance is invalid.

With respect, we have not been fine. We see problems fairly regularly
with no large page/hotplug issues with higher order allocations. 
Drivers, CIFS, kernel stacks, etc, etc etc.

The larger memory gets, the worse the problem is, just because the 
statistics make it less likely to free up multiple contiguous pages.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/