From: Boaz Harrosh <boaz@plexistor.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Oleg Nesterov <oleg@redhat.com>, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: [PATCHSET 0/2] Allow single pagefault in write access of a VM_MIXEDMAP mapping
Date: Sun, 10 Jan 2016 15:59:22 +0200 [thread overview]
Message-ID: <569263BA.5060503@plexistor.com> (raw)
Hi
Today any VM_MIXEDMAP or VM_PFN mapping when enabling a write access
to their mapping, will have a double pagefault for every write access.
This is because vma->vm_page_prot defines how a page/pfn is inserted into
the page table (see vma_wants_writenotify in mm/mmap.c).
Which means that it is always inserted with read-only under the
assumption that we want to be notified when write access occurs.
But this is not always true and adds an unnecessary page-fault on
every new mmap-write access
This patchset is trying to give the fault handler more choice by passing
an pgprot_t to vm_insert_mixed() via a new vm_insert_mixed_prot() API.
If the mm guys feel that the pgprot_t and its helpers and flags are private
to mm/memory.c I can easily do a new: vm_insert_mixed_rw() instead. of the
above vm_insert_mixed_prot() which enables any control not only write.
Following is a patch to DAX to optimize out the extra page-fault.
TODO: I only did 4k mapping perhaps 2M mapping can enjoy the same single
fault on write access. If interesting to anyone I can attempt a fix.
Dan Andrew who needs to pick this up please?
list of patches:
[PATCH 1/2] mm: Allow single pagefault on mmap-write with VM_MIXEDMAP
[PATCH 2/2] dax: Only fault once on mmap write access
Thank you
Boaz
--
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>
next reply other threads:[~2016-01-10 13:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-10 13:59 Boaz Harrosh [this message]
2016-01-10 14:02 ` [PATCH 1/2] mm: Allow single pagefault on mmap-write with VM_MIXEDMAP Boaz Harrosh
2016-01-10 14:03 ` [PATCH 2/2] dax: Only fault once on mmap write access Boaz Harrosh
2016-01-11 1:19 ` [PATCHSET 0/2] Allow single pagefault in write access of a VM_MIXEDMAP mapping Dan Williams
2016-01-11 9:22 ` Boaz Harrosh
2016-01-11 16:37 ` Dan Williams
2016-01-11 19:35 ` Matthew Wilcox
2016-01-12 13:29 ` Matthew Wilcox
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=569263BA.5060503@plexistor.com \
--to=boaz@plexistor.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=oleg@redhat.com \
--cc=ross.zwisler@linux.intel.com \
--cc=willy@linux.intel.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 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.