From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: jweiner@redhat.com
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
Subject: Re: [rfc 2/3] mm: vmscan: treat inactive cycling as neutral
Date: Wed, 02 Nov 2011 11:04:30 -0700 [thread overview]
Message-ID: <4EB1862E.8070401@jp.fujitsu.com> (raw)
In-Reply-To: <20111102163213.GI19965@redhat.com>
(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 <jweiner@redhat.com>
> ---
> 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.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-11-02 18:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 11:06 [PATCH 1/2] vmscan: promote shared file mapped pages Konstantin Khlebnikov
2011-08-08 11:07 ` [PATCH 2/2] vmscan: activate executable pages after first usage Konstantin Khlebnikov
2011-08-08 23:58 ` KAMEZAWA Hiroyuki
2011-08-09 0:02 ` Minchan Kim
2011-08-09 0:04 ` KAMEZAWA Hiroyuki
2011-08-09 0:26 ` Minchan Kim
2011-08-09 1:23 ` Shaohua Li
2011-08-08 11:37 ` [PATCH 1/2] vmscan: promote shared file mapped pages Pekka Enberg
2011-08-08 12:18 ` Konstantin Khlebnikov
2011-08-08 12:40 ` Pekka Enberg
2011-08-08 12:51 ` Konstantin Khlebnikov
2011-08-18 9:09 ` Johannes Weiner
2011-11-02 16:30 ` Johannes Weiner
2011-11-02 16:31 ` [rfc 1/3] mm: vmscan: never swap under low memory pressure Johannes Weiner
2011-11-02 17:54 ` KOSAKI Motohiro
2011-11-03 15:51 ` Johannes Weiner
2011-11-08 0:16 ` KOSAKI Motohiro
2011-11-07 2:29 ` KAMEZAWA Hiroyuki
2011-11-10 15:29 ` Johannes Weiner
2011-11-02 16:32 ` [rfc 2/3] mm: vmscan: treat inactive cycling as neutral Johannes Weiner
2011-11-02 18:04 ` KOSAKI Motohiro [this message]
2011-11-03 12:49 ` Johannes Weiner
2011-11-07 2:34 ` KAMEZAWA Hiroyuki
2011-11-10 16:06 ` Johannes Weiner
2011-11-11 0:05 ` KAMEZAWA Hiroyuki
2011-11-02 16:32 ` [rfc 3/3] mm: vmscan: revert file list boost on lru addition Johannes Weiner
2011-11-07 2:45 ` KAMEZAWA Hiroyuki
2011-11-10 16:12 ` Johannes Weiner
2011-11-02 16:35 ` [PATCH 1/2] vmscan: promote shared file mapped pages Johannes Weiner
2011-08-08 23:36 ` Minchan Kim
2011-08-08 23:51 ` KAMEZAWA Hiroyuki
2011-10-31 20:12 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EB1862E.8070401@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=gene.heskett@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=jweiner@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=khlebnikov@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox