Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752510Ab0HALQR (ORCPT ); Sun, 1 Aug 2010 07:16:17 -0400 Received: from mga14.intel.com ([143.182.124.37]:6270 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751748Ab0HALQQ (ORCPT ); Sun, 1 Aug 2010 07:16:16 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.55,297,1278313200"; d="scan'208";a="306827968" Date: Sun, 1 Aug 2010 19:15:44 +0800 From: Wu Fengguang To: Andrew Morton Cc: Jens Axboe , Mel Gorman , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , Dave Chinner , Chris Mason , Nick Piggin , Rik van Riel , Johannes Weiner , Christoph Hellwig , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Andrea Arcangeli Subject: Re: [PATCH 6/6] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages Message-ID: <20100801111544.GC7515@localhost> References: <1280497020-22816-1-git-send-email-mel@csn.ul.ie> <1280497020-22816-7-git-send-email-mel@csn.ul.ie> <20100730150601.199c5618.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100730150601.199c5618.akpm@linux-foundation.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1895 Lines: 57 > Sigh. We have sooo many problems with writeback and latency. Read > https://bugzilla.kernel.org/show_bug.cgi?id=12309 and weep. Everyone's > running away from the issue and here we are adding code to solve some > alleged stack-overflow problem which seems to be largely a non-problem, > by making changes which may worsen our real problems. This looks like some vmscan/writeback interaction issue. Firstly, the CFQ io scheduler can already prevent read IO from being delayed by lots of ASYNC write IO. See the commits 365722bb/8e2967555 in late 2009. Reading a big file in an idle system: 680897928 bytes (681 MB) copied, 15.8986 s, 42.8 MB/s Reading a big file while doing sequential writes to another file: 680897928 bytes (681 MB) copied, 27.6007 s, 24.7 MB/s 680897928 bytes (681 MB) copied, 25.6592 s, 26.5 MB/s So CFQ offers reasonable read performance under heavy writeback. Secondly, I can only feel the responsiveness lags when there are memory pressures _in addition to_ heavy writeback. cp /dev/zero /tmp No lags. usemem 1g --sleep 1000 Still no lags. usemem 1g --sleep 1000 Still no lags. usemem 1g --sleep 1000 Begin to feel lags at times. My desktop has 4G memory and no swap space. So the lags are correlated with page reclaim pressure. The above symptoms are matched very well by the patches posted by KOSAKI and me: - vmscan: raise the bar to PAGEOUT_IO_SYNC stalls - vmscan: synchronous lumpy reclaim don't call congestion_wait() However kernels as early as 2.6.18 are reported to have the problem, so there may be more hidden issues. 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/