RE: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures
From: Satoru Moriya <hidden>
Date: 2011-05-03 01:00:28
Also in:
lkml
Hi Wu,
On Mon, May 02, 2011 at 09:29:58PM +0800, Wu Fengguang wrote:quoted
quoted
quoted
+ if (preferred_zone && + zone_watermark_ok_safe(preferred_zone, sc->order, + high_wmark_pages(preferred_zone), + zone_idx(preferred_zone), 0)) + goto out; + }As I said, I think direct reclaim path sould be fast if possbile and it should not a function of min_free_kbytes.It can be made not a function of min_free_kbytes by simply changing high_wmark_pages() to low_wmark_pages() in the above chunk, since direct reclaim is triggered when ALLOC_WMARK_LOW cannot be satisfied, ie. it just dropped below low_wmark_pages(). But still, it costs 62ms reclaim latency (base kernel is 29ms).I got new findings: the CPU schedule delays are much larger than reclaim delays. It does make the "direct reclaim until low watermark OK" latency less a problem :) 1000 dd test case: RECLAIM delay CPU delay nr_alloc_fail CAL (last CPU) base kernel 29ms 244ms 14586 218440 patched 62ms 215ms 5004 325
Hmm, in your system, the latency of direct reclaim may be a less problem. But, generally speaking, in a latency sensitive system in enterprise area there are two kind of processes. One is latency sensitive -(A) the other is not-latency sensitive -(B). And usually we set cpu affinity for both processes to avoid scheduling issue in (A). In this situation, CPU delay tends to be lower than the above and a less problem but reclaim delay is more critical. Regards, Satoru
Thanks, Fengguang
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>