Re: [PATCH 61 of 66] use compaction for GFP_ATOMIC order > 0

[Andrea Arcangeli]

On Tue, Nov 09, 2010 at 07:27:37PM +0900, KOSAKI Motohiro wrote:
> > From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> > 
> > This takes advantage of memory compaction to properly generate pages of order >
> > 0 if regular page reclaim fails and priority level becomes more severe and we
> > don't reach the proper watermarks.
> > 
> > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> 
> First, I don't think this patch is related to GFP_ATOMIC. So, I think the 
> patch title is a bit misleading.
> 
> Second, this patch has two changes. 1) remove PAGE_ALLOC_COSTLY_ORDER 
> threshold 2) implement background compaction. please separate them.

Well the subject isn't entirely misleading: background compaction in
kswapd is only for the GFP_ATOMIC so GFP_ATOMIC order >0 allocations
are definitely related to this patch.

Then I ended up then allowing compaction for all order of allocations
as it doesn't make sense to fail order 2 for the kernel stack and
succeed order 9 but it's true I can split that off, I will split it
for #33, thanks for allowing me to clean up the stuff better.

> Third, This patch makes a lot of PFN order page scan and churn LRU
> aggressively. I'm not sure this aggressive lru shuffling is safe and
> works effective. I hope you provide some demonstration and/or show 
> benchmark result.

The patch will increase the amount of compaction for GFP_ATOMIC order
>0, but it won't alter the amount of free pages in the system, but
it'll satisfy the in-function-of order watermarks that are right now
ignored. If user asked GFP_ATOMIC order > 0, this is what it asks,
it's up to the user not to ask for it if it's not worthwhile. If user
doesn't want this but it just wants to poll the LRU it should use
GFP_ATOMIC|__GFP_NO_KSWAPD.

The benchmark results I don't have at the moment but this has been
tested with tg3 with jumbo packets that trigger order 2 allocation and
no degradation was noticed. To be fair it didn't significantly improve
the amount of order 2 (9046 bytes large skb) allocated from irq
though, but I thought it was good idea to keep it in case there are
less aggressive/frequent users doing similar things.

Overall the more important part of the patch is the point 2) that I
can make it cleaner by splitting it off as you noticed and I will do
it.
--
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/