linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ken Chen <kenchen@google.com>
Cc: Hugh Dickins <hugh@veritas.com>, Andrew Morton <akpm@osdl.org>,
	linux-mm@kvack.org
Subject: Re: [patch] not to disturb page LRU state when unmapping memory range
Date: Wed, 31 Jan 2007 13:26:36 +0100	[thread overview]
Message-ID: <1170246396.9516.39.camel@twins> (raw)
In-Reply-To: <b040c32a0701302041j2a99e2b6p91b0b4bfa065444a@mail.gmail.com>

On Tue, 2007-01-30 at 20:41 -0800, Ken Chen wrote:
> I stomped on another piece of code in zap_pte_range() that is a bit
> questionable: when kernel unmaps an address range, it needs to transfer
> PTE state into page struct. Currently, kernel transfer both dirty bit
> and access bit via set_page_dirty and mark_page_accessed.
> 
> set_page_dirty is necessary and required.  However, transfering access
> bit doesn't look logical.  Kernel usually mark the page accessed at the
> time of fault, for example shmem_nopage() does so.  At unmap, another
> call to mark_page_accessed is called and this causes page LRU state to
> be bumped up one step closer to more recently used state. It is causing
> quite a bit headache in a scenario when a process creates a shmem segment,
> touch a whole bunch of pages, then unmaps it. The unmapping takes a long
> time because mark_page_accessed() will start moving pages from inactive
> to active list.
> 
> I'm not too much concerned with moving the page from one list to another
> in LRU. Sooner or later it might be moved because of multiple mappings
> from various processes.  But it just doesn't look logical that when user
> asks a range to be unmapped, it's his intention that the process is no
> longer interested in these pages. Moving those pages to active list (or
> bumping up a state towards more active) seems to be an over reaction. It
> also prolongs unmapping latency which is the core issue I'm trying to solve.
> 
> Given that the LRU state is maintained properly at fault time, I think we
> should remove it in the unmap path.

We do not maintain the accessed state with faults. We might set an
initial ref bit, but thereafter it is up to page reclaim to scan for pte
young pages.

So by blindly removing the mark_page_accessed() call we do lose
information, it might have been recently referenced and it might still
be relevant (think of sliding mmaps and such).

That said, I think mark_page_accessed() does the wrong thing here, if it
were the page scanner that would pass by it would only act as if
PageReferenced() were set.

So may I suggest the following?

It preserves the information, but not more.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
diff --git a/mm/memory.c b/mm/memory.c
index ef09f0a..b1f9129 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -678,7 +678,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 				if (pte_dirty(ptent))
 					set_page_dirty(page);
 				if (pte_young(ptent))
-					mark_page_accessed(page);
+					SetPageReferenced(page);
 				file_rss--;
 			}
 			page_remove_rmap(page, vma);


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-01-31 12:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-31  4:41 [patch] not to disturb page LRU state when unmapping memory range Ken Chen
2007-01-31 12:26 ` Peter Zijlstra [this message]
2007-01-31 19:15   ` Balbir Singh
2007-01-31 19:30     ` Christoph Lameter
2007-01-31 18:02 ` Hugh Dickins
2007-01-31 21:43   ` Peter Zijlstra
2007-01-31 21:51     ` Ken Chen
2007-01-31 22:04     ` Andrew Morton
2007-01-31 22:25       ` Peter Zijlstra
2007-01-31 22:48         ` Andrew Morton
2007-01-31 23:52           ` Peter Zijlstra
2007-02-01  0:33             ` Andrew Morton
2007-02-01  3:21           ` Rik van Riel
2007-02-01  3:13         ` Rik van Riel

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=1170246396.9516.39.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=kenchen@google.com \
    --cc=linux-mm@kvack.org \
    /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;
as well as URLs for NNTP newsgroup(s).