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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>