Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758988Ab1ECBA2 (ORCPT ); Mon, 2 May 2011 21:00:28 -0400 Received: from usindmx01.hds.com ([207.126.252.12]:43570 "EHLO usindmx01.hds.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758924Ab1ECBAX convert rfc822-to-8bit (ORCPT ); Mon, 2 May 2011 21:00:23 -0400 X-Greylist: delayed 1904 seconds by postgrey-1.27 at vger.kernel.org; Mon, 02 May 2011 21:00:23 EDT From: Satoru Moriya To: Wu Fengguang , Minchan Kim CC: Andrew Morton , Mel Gorman , Dave Young , linux-mm , Linux Kernel Mailing List , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Christoph Lameter , Dave Chinner , David Rientjes Date: Mon, 2 May 2011 20:27:43 -0400 Subject: RE: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures Thread-Topic: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures Thread-Index: AcwIz9zupkxMcsC9RtSiVb/bU06c5wAVlr8g Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9C3DED479C@USINDEVS02.corp.hds.com> References: <20110426063421.GC19717@localhost> <20110426092029.GA27053@localhost> <20110426124743.e58d9746.akpm@linux-foundation.org> <20110428133644.GA12400@localhost> <20110429022824.GA8061@localhost> <20110430141741.GA4511@localhost> <20110501163542.GA3204@barrios-desktop> <20110502132958.GA9690@localhost> <20110502134953.GA12281@localhost> In-Reply-To: <20110502134953.GA12281@localhost> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2080 Lines: 50 Hi Wu, > On Mon, May 02, 2011 at 09:29:58PM +0800, Wu Fengguang wrote: > > > > + 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 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/