[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090609175211.DD85.A69D9226@jp.fujitsu.com>
Date: Tue, 9 Jun 2009 17:55:03 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Mel Gorman <mel@....ul.ie>
Cc: kosaki.motohiro@...fujitsu.com,
Wu Fengguang <fengguang.wu@...el.com>,
Rik van Riel <riel@...hat.com>,
Christoph Lameter <cl@...ux-foundation.org>,
"Zhang, Yanmin" <yanmin.zhang@...el.com>,
"linuxram@...ibm.com" <linuxram@...ibm.com>,
linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] Properly account for the number of page cache pages zone_reclaim() can reclaim
> > > The ideal would be that the number of tmpfs pages would also be known
> > > and account for like NR_FILE_MAPPED as swap is required to discard them.
> > > A means of working this out quickly was not obvious but a comment is added
> > > noting the problem.
> >
> > I'd rather prefer it be accounted separately than to muck up NR_FILE_MAPPED :)
> >
>
> Maybe I used a poor choice of words. What I meant was that the ideal would
> be we had a separate count for tmpfs pages. As tmpfs pages and mapped pages
> both have to be unmapped and potentially, they are "like" each other with
> respect to the zone_reclaim_mode and how it behaves. We would end up
> with something like
>
> pagecache_reclaimable -= zone_page_state(zone, NR_FILE_MAPPED);
> pagecache_reclaimable -= zone_page_state(zone, NR_FILE_TMPFS);
Please see shmem_writepage(). tmpfs writeout make swapcache, We also
need to concern swapcache.
note: swapcache also increase NR_FILE_PAGES, see add_to_swap_cache.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists