linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.com,
	riel@redhat.com, minchan@google.com, hannes@cmpxchg.org,
	kirill.shutemov@linux.intel.com
Subject: rmap for shmem pages
Date: Wed, 11 Dec 2019 18:51:08 -0500	[thread overview]
Message-ID: <20191211235108.GA85068@google.com> (raw)

Hi,
I am looking into a weird behavior of the VmRSS counter in /proc/pid/status
which I think is a bug.

The issue is if a memfd is mapped into the same process twice as MAP_SHARED, and
you write to both maps, then the RSS doubles even though the pages were
mapped elsewhere within the same address space before. We expect RSS to
increase only once in this case, not twice.

Digging further, I see the RssShmem is contributing to this increase and this
happens in alloc_set_pte() during a page fault. I tried to write a patch to
check if the page is mapped within the same process already, and if not,
don't do the increment as the accounting was already previously done. However
for shmem pages, it appears rmap has no effect and cannot detect the case I
am interested in.

The patch below is obviously incomplete since I didn't handle the unmap case,
but could anyone let me know why rmap does not seem to be working for shmem,
and is this expected?

I was expecting the RSS increment to be skipped since the code should find that the
page was mapped locally within same address space already.

---8<-----------------------

diff --git a/mm/memory.c b/mm/memory.c
index 606da187d1de..4fca5d7e9d66 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3360,6 +3361,8 @@ static vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
  *
  * Return: %0 on success, %VM_FAULT_ code in case of error.
  */
+bool page_has_single_mm(struct page *page, struct mm_struct *mm);
+
 vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg,
 		struct page *page)
 {
@@ -3399,8 +3402,14 @@ vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg,
 		mem_cgroup_commit_charge(page, memcg, false, false);
 		lru_cache_add_active_or_unevictable(page, vma);
 	} else {
-		inc_mm_counter_fast(vma->vm_mm, mm_counter_file(page));
 		page_add_file_rmap(page, false);
+
+		if (page_has_single_mm(page, vma->vm_mm)) {
+			trace_printk("inc 2 mm_counter_file counter=%d\n", mm_counter_file(page));
+			inc_mm_counter_fast(vma->vm_mm, mm_counter_file(page));
+		} else {
+			trace_printk("inc 2 mm_counter_file counter=%d skipped\n", mm_counter_file(page));
+		}
 	}
 	set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
 
diff --git a/mm/rmap.c b/mm/rmap.c
index b3e381919835..580da8469f0d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1273,6 +1273,39 @@ static void page_remove_file_rmap(struct page *page, bool compound)
 	unlock_page_memcg(page);
 }
 
+struct page_single_mm_ctx {
+	struct mm_struct *mm;
+	bool single;
+};
+
+static bool __page_has_single_mm(struct page *page, struct vm_area_struct *vma,
+				 unsigned long addr, void *ctx_in)
+{
+	struct page_single_mm_ctx *ctx = ctx_in;
+
+	if (vma->vm_mm == ctx->mm)
+		return true;
+
+	ctx->single = false;
+	return false;
+}
+
+bool page_has_single_mm(struct page *page, struct mm_struct *mm)
+{
+	struct page_single_mm_ctx ctx;
+
+	ctx.mm = mm;
+	ctx.single = true;
+
+	struct rmap_walk_control rwc = {
+		.rmap_one = __page_has_single_mm,
+		.arg = &ctx,
+	};
+
+	rmap_walk(page, &rwc);
+	return ctx.single;
+}
+
 static void page_remove_anon_compound_rmap(struct page *page)
 {
 	int i, nr;
-- 
2.24.0.525.g8f36a354ae-goog



             reply	other threads:[~2019-12-11 23:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 23:51 Joel Fernandes [this message]
2019-12-12 10:55 ` Kirill A. Shutemov
2019-12-12 14:43   ` Joel Fernandes

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=20191211235108.GA85068@google.com \
    --to=joel@joelfernandes.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@google.com \
    --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