From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755668Ab1HROCP (ORCPT ); Thu, 18 Aug 2011 10:02:15 -0400 Received: from mga14.intel.com ([143.182.124.37]:36262 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755261Ab1HROCO (ORCPT ); Thu, 18 Aug 2011 10:02:14 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,245,1312182000"; d="scan'208";a="39832147" Date: Thu, 18 Aug 2011 22:02:08 +0800 From: Wu Fengguang To: Mel Gorman Cc: Linux-MM , LKML , XFS , Dave Chinner , Christoph Hellwig , Johannes Weiner , Jan Kara , Rik van Riel , Minchan Kim Subject: Re: [PATCH 6/7] mm: vmscan: Throttle reclaim if encountering too many dirty pages under writeback Message-ID: <20110818140208.GA21003@localhost> References: <1312973240-32576-1-git-send-email-mgorman@suse.de> <1312973240-32576-7-git-send-email-mgorman@suse.de> <20110816140652.GC13391@localhost> <20110816150208.GD4844@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110816150208.GD4844@suse.de> 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 On Tue, Aug 16, 2011 at 11:02:08PM +0800, Mel Gorman wrote: > On Tue, Aug 16, 2011 at 10:06:52PM +0800, Wu Fengguang wrote: > > Mel, > > > > I tend to agree with the whole patchset except for this one. > > > > The worry comes from the fact that there are always the very possible > > unevenly distribution of dirty pages throughout the LRU lists. > > It is pages under writeback that determines if throttling is considered > not dirty pages. The distinction is important. I agree with you that if > it was dirty pages that throttling would be considered too regularly. Ah right, sorry for the rushed conclusion! btw, I guess the vmscan will now progress faster due to the reduced ->pageout() and implicitly blocks in get_request_wait() on congested IO queue. > > This > > patch works on local information and may unnecessarily throttle page > > reclaim when running into small spans of dirty pages. > > > > It's also calling wait_iff_congested() not congestion_wait(). This > takes BDI congestion and zone congestion into account with this check. > > /* > * If there is no congestion, or heavy congestion is not being > * encountered in the current zone, yield if necessary instead > * of sleeping on the congestion queue > */ > if (atomic_read(&nr_bdi_congested[sync]) == 0 || > !zone_is_reclaim_congested(zone)) { > > So global information is being taken into account. That's right. > > One possible scheme of global throttling is to first tag the skipped > > page with PG_reclaim (as you already do). And to throttle page reclaim > > only when running into pages with both PG_dirty and PG_reclaim set, > > It's PG_writeback that is looked at, not PG_dirty. > > > which means we have cycled through the _whole_ LRU list (which is the > > global and adaptive feedback we want) and run into that dirty page for > > the second time. > > > > This potentially results in more scanning from kswapd before it starts > throttling which could consume a lot of CPU. If pages under writeback > are reaching the end of the LRU, it's already the case that kswapd is > scanning faster than pages can be cleaned. Even then, it only really > throttles if the zone or a BDI is congested. Yeah, the first round may already eat a lot of CPU power.. > Taking that into consideration, do you still think there is a big > advantage to having writeback pages take another lap around the LRU > that is justifies the expected increase in CPU usage? Given that there are typically much fewer PG_writeback than PG_dirty (except for btrfs which probably should be fixed), the current throttle condition should be strong enough to avoid false positives. I even start to worry on the opposite side -- it could be less throttled than necessary when some LRU is full of dirty pages and somehow the flusher failed to focus on those pages (hence there are no enough PG_writeback to wait upon at all). In this case it may help to do "wait on PG_dirty&PG_reclaim and/or PG_writeback&PG_reclaim". But the most essential task is always to let the flusher focus more on the pages, rather than the question of to-sleep-or-not-to-sleep, which will either block the direct reclaim tasks for arbitrary long time, or act even worse by busy burning the CPU during the time. Thanks, Fengguang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p7IE2FZn176985 for ; Thu, 18 Aug 2011 09:02:15 -0500 Received: from mga14.intel.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC47753F062 for ; Thu, 18 Aug 2011 07:02:14 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by cuda.sgi.com with ESMTP id bdihfITEPQVqFJuv for ; Thu, 18 Aug 2011 07:02:14 -0700 (PDT) Date: Thu, 18 Aug 2011 22:02:08 +0800 From: Wu Fengguang Subject: Re: [PATCH 6/7] mm: vmscan: Throttle reclaim if encountering too many dirty pages under writeback Message-ID: <20110818140208.GA21003@localhost> References: <1312973240-32576-1-git-send-email-mgorman@suse.de> <1312973240-32576-7-git-send-email-mgorman@suse.de> <20110816140652.GC13391@localhost> <20110816150208.GD4844@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20110816150208.GD4844@suse.de> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Mel Gorman Cc: Rik van Riel , Jan Kara , LKML , XFS , Christoph Hellwig , Linux-MM , Minchan Kim , Johannes Weiner On Tue, Aug 16, 2011 at 11:02:08PM +0800, Mel Gorman wrote: > On Tue, Aug 16, 2011 at 10:06:52PM +0800, Wu Fengguang wrote: > > Mel, > > > > I tend to agree with the whole patchset except for this one. > > > > The worry comes from the fact that there are always the very possible > > unevenly distribution of dirty pages throughout the LRU lists. > > It is pages under writeback that determines if throttling is considered > not dirty pages. The distinction is important. I agree with you that if > it was dirty pages that throttling would be considered too regularly. Ah right, sorry for the rushed conclusion! btw, I guess the vmscan will now progress faster due to the reduced ->pageout() and implicitly blocks in get_request_wait() on congested IO queue. > > This > > patch works on local information and may unnecessarily throttle page > > reclaim when running into small spans of dirty pages. > > > > It's also calling wait_iff_congested() not congestion_wait(). This > takes BDI congestion and zone congestion into account with this check. > > /* > * If there is no congestion, or heavy congestion is not being > * encountered in the current zone, yield if necessary instead > * of sleeping on the congestion queue > */ > if (atomic_read(&nr_bdi_congested[sync]) == 0 || > !zone_is_reclaim_congested(zone)) { > > So global information is being taken into account. That's right. > > One possible scheme of global throttling is to first tag the skipped > > page with PG_reclaim (as you already do). And to throttle page reclaim > > only when running into pages with both PG_dirty and PG_reclaim set, > > It's PG_writeback that is looked at, not PG_dirty. > > > which means we have cycled through the _whole_ LRU list (which is the > > global and adaptive feedback we want) and run into that dirty page for > > the second time. > > > > This potentially results in more scanning from kswapd before it starts > throttling which could consume a lot of CPU. If pages under writeback > are reaching the end of the LRU, it's already the case that kswapd is > scanning faster than pages can be cleaned. Even then, it only really > throttles if the zone or a BDI is congested. Yeah, the first round may already eat a lot of CPU power.. > Taking that into consideration, do you still think there is a big > advantage to having writeback pages take another lap around the LRU > that is justifies the expected increase in CPU usage? Given that there are typically much fewer PG_writeback than PG_dirty (except for btrfs which probably should be fixed), the current throttle condition should be strong enough to avoid false positives. I even start to worry on the opposite side -- it could be less throttled than necessary when some LRU is full of dirty pages and somehow the flusher failed to focus on those pages (hence there are no enough PG_writeback to wait upon at all). In this case it may help to do "wait on PG_dirty&PG_reclaim and/or PG_writeback&PG_reclaim". But the most essential task is always to let the flusher focus more on the pages, rather than the question of to-sleep-or-not-to-sleep, which will either block the direct reclaim tasks for arbitrary long time, or act even worse by busy burning the CPU during the time. Thanks, Fengguang _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id D5287900138 for ; Thu, 18 Aug 2011 10:02:27 -0400 (EDT) Date: Thu, 18 Aug 2011 22:02:08 +0800 From: Wu Fengguang Subject: Re: [PATCH 6/7] mm: vmscan: Throttle reclaim if encountering too many dirty pages under writeback Message-ID: <20110818140208.GA21003@localhost> References: <1312973240-32576-1-git-send-email-mgorman@suse.de> <1312973240-32576-7-git-send-email-mgorman@suse.de> <20110816140652.GC13391@localhost> <20110816150208.GD4844@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110816150208.GD4844@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Linux-MM , LKML , XFS , Dave Chinner , Christoph Hellwig , Johannes Weiner , Jan Kara , Rik van Riel , Minchan Kim On Tue, Aug 16, 2011 at 11:02:08PM +0800, Mel Gorman wrote: > On Tue, Aug 16, 2011 at 10:06:52PM +0800, Wu Fengguang wrote: > > Mel, > > > > I tend to agree with the whole patchset except for this one. > > > > The worry comes from the fact that there are always the very possible > > unevenly distribution of dirty pages throughout the LRU lists. > > It is pages under writeback that determines if throttling is considered > not dirty pages. The distinction is important. I agree with you that if > it was dirty pages that throttling would be considered too regularly. Ah right, sorry for the rushed conclusion! btw, I guess the vmscan will now progress faster due to the reduced ->pageout() and implicitly blocks in get_request_wait() on congested IO queue. > > This > > patch works on local information and may unnecessarily throttle page > > reclaim when running into small spans of dirty pages. > > > > It's also calling wait_iff_congested() not congestion_wait(). This > takes BDI congestion and zone congestion into account with this check. > > /* > * If there is no congestion, or heavy congestion is not being > * encountered in the current zone, yield if necessary instead > * of sleeping on the congestion queue > */ > if (atomic_read(&nr_bdi_congested[sync]) == 0 || > !zone_is_reclaim_congested(zone)) { > > So global information is being taken into account. That's right. > > One possible scheme of global throttling is to first tag the skipped > > page with PG_reclaim (as you already do). And to throttle page reclaim > > only when running into pages with both PG_dirty and PG_reclaim set, > > It's PG_writeback that is looked at, not PG_dirty. > > > which means we have cycled through the _whole_ LRU list (which is the > > global and adaptive feedback we want) and run into that dirty page for > > the second time. > > > > This potentially results in more scanning from kswapd before it starts > throttling which could consume a lot of CPU. If pages under writeback > are reaching the end of the LRU, it's already the case that kswapd is > scanning faster than pages can be cleaned. Even then, it only really > throttles if the zone or a BDI is congested. Yeah, the first round may already eat a lot of CPU power.. > Taking that into consideration, do you still think there is a big > advantage to having writeback pages take another lap around the LRU > that is justifies the expected increase in CPU usage? Given that there are typically much fewer PG_writeback than PG_dirty (except for btrfs which probably should be fixed), the current throttle condition should be strong enough to avoid false positives. I even start to worry on the opposite side -- it could be less throttled than necessary when some LRU is full of dirty pages and somehow the flusher failed to focus on those pages (hence there are no enough PG_writeback to wait upon at all). In this case it may help to do "wait on PG_dirty&PG_reclaim and/or PG_writeback&PG_reclaim". But the most essential task is always to let the flusher focus more on the pages, rather than the question of to-sleep-or-not-to-sleep, which will either block the direct reclaim tasks for arbitrary long time, or act even worse by busy burning the CPU during the time. 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: email@kvack.org