All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Andy Lutomirski <luto@kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH] mm: do not let vdso pages into LRU rotation
Date: Wed, 27 Jan 2016 14:39:58 -0500	[thread overview]
Message-ID: <20160127193958.GA31407@cmpxchg.org> (raw)

Hi,

I noticed that vdso pages are faulted and unmapped as if they were
regular file pages. And I'm guessing this is so that the vdso mappings
are able to use the generic COW code in memory.c.

However, it's a little unsettling that zap_pte_range() makes decisions
based on PageAnon() and the page even reaches mark_page_accessed(), as
that function makes several assumptions about the page being a regular
LRU user page. It seems this isn't crashing today by sheer luck, but I
am working on code that does when page_is_file_cache() returns garbage.

I'm using this hack to work around it:

diff --git a/mm/memory.c b/mm/memory.c
index c387430f06c3..f0537c500150 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1121,7 +1121,8 @@ again:
 					set_page_dirty(page);
 				}
 				if (pte_young(ptent) &&
-				    likely(!(vma->vm_flags & VM_SEQ_READ)))
+				    likely(!(vma->vm_flags & VM_SEQ_READ)) &&
+				    !PageReserved(page))
 					mark_page_accessed(page);
 				rss[MM_FILEPAGES]--;
 			}

but I think we need a cleaner (and more robust) solution there to make
it clearer that these pages are not regularly managed pages.

Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
out of the VM while allowing COW into regular anonymous pages?

Are there other requirements of the VDSO that I might be missing?

Any feedback would be greatly appreciated.

Thanks!
Johannes

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Andy Lutomirski <luto@kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH] mm: do not let vdso pages into LRU rotation
Date: Wed, 27 Jan 2016 14:39:58 -0500	[thread overview]
Message-ID: <20160127193958.GA31407@cmpxchg.org> (raw)

Hi,

I noticed that vdso pages are faulted and unmapped as if they were
regular file pages. And I'm guessing this is so that the vdso mappings
are able to use the generic COW code in memory.c.

However, it's a little unsettling that zap_pte_range() makes decisions
based on PageAnon() and the page even reaches mark_page_accessed(), as
that function makes several assumptions about the page being a regular
LRU user page. It seems this isn't crashing today by sheer luck, but I
am working on code that does when page_is_file_cache() returns garbage.

I'm using this hack to work around it:

diff --git a/mm/memory.c b/mm/memory.c
index c387430f06c3..f0537c500150 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1121,7 +1121,8 @@ again:
 					set_page_dirty(page);
 				}
 				if (pte_young(ptent) &&
-				    likely(!(vma->vm_flags & VM_SEQ_READ)))
+				    likely(!(vma->vm_flags & VM_SEQ_READ)) &&
+				    !PageReserved(page))
 					mark_page_accessed(page);
 				rss[MM_FILEPAGES]--;
 			}

but I think we need a cleaner (and more robust) solution there to make
it clearer that these pages are not regularly managed pages.

Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages
out of the VM while allowing COW into regular anonymous pages?

Are there other requirements of the VDSO that I might be missing?

Any feedback would be greatly appreciated.

Thanks!
Johannes

             reply	other threads:[~2016-01-27 19:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 19:39 Johannes Weiner [this message]
2016-01-27 19:39 ` [PATCH] mm: do not let vdso pages into LRU rotation Johannes Weiner
2016-01-27 20:32 ` Andy Lutomirski
2016-01-27 20:32   ` Andy Lutomirski
2016-01-28 21:33   ` Johannes Weiner
2016-01-28 21:33     ` Johannes Weiner
2016-01-29 22:21     ` Andy Lutomirski
2016-01-29 22:21       ` Andy Lutomirski

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=20160127193958.GA31407@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.