From: Boaz Harrosh <boaz@plexistor.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Oleg Nesterov <oleg@redhat.com>, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCHSET 0/2] Allow single pagefault in write access of a VM_MIXEDMAP mapping
Date: Mon, 11 Jan 2016 11:22:14 +0200 [thread overview]
Message-ID: <56937446.1050308@plexistor.com> (raw)
In-Reply-To: <CAPcyv4hb6T9cR2Z=G9U_U2q-i_wEmRwNCrkc8kK9YpH9RkS9cA@mail.gmail.com>
On 01/11/2016 03:19 AM, Dan Williams wrote:
> On Sun, Jan 10, 2016 at 5:59 AM, Boaz Harrosh <boaz@plexistor.com> wrote:
>> 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?
>
> This collides with the patches currently pending in -mm for 4.5, lets
> take a look at this for 4.6.
>
OK thanks, I will try to work this over current linux-next and sure we
will wait for 4.5-rc1 to look at this again.
Do you have any comments in general about this?
Thanks
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 prev parent reply other threads:[~2016-01-11 9:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-10 13:59 [PATCHSET 0/2] Allow single pagefault in write access of a VM_MIXEDMAP mapping Boaz Harrosh
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 [this message]
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=56937446.1050308@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.