From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id 0E16A6B0069 for ; Thu, 3 Nov 2011 08:50:46 -0400 (EDT) Date: Thu, 3 Nov 2011 13:49:38 +0100 From: Johannes Weiner Subject: Re: [rfc 2/3] mm: vmscan: treat inactive cycling as neutral Message-ID: <20111103124938.GL19965@redhat.com> References: <20110808110658.31053.55013.stgit@localhost6> <4E3FD403.6000400@parallels.com> <20111102163056.GG19965@redhat.com> <20111102163213.GI19965@redhat.com> <4EB1862E.8070401@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB1862E.8070401@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: To: KOSAKI Motohiro Cc: khlebnikov@parallels.com, penberg@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, fengguang.wu@intel.com, kamezawa.hiroyu@jp.fujitsu.com, hannes@cmpxchg.org, riel@redhat.com, mel@csn.ul.ie, minchan.kim@gmail.com, gene.heskett@gmail.com On Wed, Nov 02, 2011 at 11:04:30AM -0700, KOSAKI Motohiro wrote: > (11/2/2011 9:32 AM), Johannes Weiner wrote: > > Each page that is scanned but put back to the inactive list is counted > > as a successful reclaim, which tips the balance between file and anon > > lists more towards the cycling list. > > > > This does - in my opinion - not make too much sense, but at the same > > time it was not much of a problem, as the conditions that lead to an > > inactive list cycle were mostly temporary - locked page, concurrent > > page table changes, backing device congested - or at least limited to > > a single reclaimer that was not allowed to unmap or meddle with IO. > > More important than being moderately rare, those conditions should > > apply to both anon and mapped file pages equally and balance out in > > the end. > > > > Recently, we started cycling file pages in particular on the inactive > > list much more aggressively, for used-once detection of mapped pages, > > and when avoiding writeback from direct reclaim. > > > > Those rotated pages do not exactly speak for the reclaimability of the > > list they sit on and we risk putting immense pressure on file list for > > no good reason. > > > > Instead, count each page not reclaimed and put back to any list, > > active or inactive, as rotated, so they are neutral with respect to > > the scan/rotate ratio of the list class, as they should be. > > > > Signed-off-by: Johannes Weiner > > --- > > mm/vmscan.c | 9 ++++----- > > 1 files changed, 4 insertions(+), 5 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 39d3da3..6da66a7 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -1360,7 +1360,9 @@ putback_lru_pages(struct zone *zone, struct scan_control *sc, > > */ > > spin_lock(&zone->lru_lock); > > while (!list_empty(page_list)) { > > + int file; > > int lru; > > + > > page = lru_to_page(page_list); > > VM_BUG_ON(PageLRU(page)); > > list_del(&page->lru); > > @@ -1373,11 +1375,8 @@ putback_lru_pages(struct zone *zone, struct scan_control *sc, > > SetPageLRU(page); > > lru = page_lru(page); > > add_page_to_lru_list(zone, page, lru); > > - if (is_active_lru(lru)) { > > - int file = is_file_lru(lru); > > - int numpages = hpage_nr_pages(page); > > - reclaim_stat->recent_rotated[file] += numpages; > > - } > > + file = is_file_lru(lru); > > + reclaim_stat->recent_rotated[file] += hpage_nr_pages(page); > > if (!pagevec_add(&pvec, page)) { > > spin_unlock_irq(&zone->lru_lock); > > __pagevec_release(&pvec); > > When avoiding writeback from direct reclaim case, I think we shouldn't increase > recent_rotated because VM decided "the page should be eviceted, but also it > should be delayed". i'm not sure it's minor factor or not. But we DO increase recent_scanned another time when the page is reclaimed on the next round. If we don't increase recent_rotated for deferred reclaims, they are counted as success twice and so considered more valuable than immediate reclaims. I don't think that makes sense. -- 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