Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1321077 > unrolled thread
| Started by | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| First post | 2016-01-28 22:40 +0100 |
| Last post | 2016-01-29 23:30 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] mm: do not let vdso pages into LRU rotation Johannes Weiner <hannes@cmpxchg.org> - 2016-01-28 22:40 +0100
Re: [PATCH] mm: do not let vdso pages into LRU rotation Andy Lutomirski <luto@amacapital.net> - 2016-01-29 23:30 +0100
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-01-28 22:40 +0100 |
| Subject | Re: [PATCH] mm: do not let vdso pages into LRU rotation |
| Message-ID | <qW2si-Yt-15@gated-at.bofh.it> |
On Wed, Jan 27, 2016 at 12:32:16PM -0800, Andy Lutomirski wrote: > On Wed, Jan 27, 2016 at 11:39 AM, Johannes Weiner <hannes@cmpxchg.org> wrote: > > Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages > > out of the VM while allowing COW into regular anonymous pages? > > Probably. What are its limitations? We want ptrace to work on it, > and mprotect needs to work and allow COW. access_process_vm should > probably work, too. Thanks, that's good to know. However, after looking at this a little longer, it appears this would need work in do_wp_page() to support non-page COW copying, then adding vm_ops->access and complicating ->fault in all VDSO implementations. And it looks like - at least theoretically - drivers can inject non-VM pages into the page tables as well (comment above insert_page()) Given that this behavior has been around for a long time (the comment at the bottom of vm_normal_page is ancient), I'll probably go with a more conservative approach; add a comment to mark_page_accessed() and filter out non-VM pages in the function I'm going to call from it. Thanks!
[toc] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-01-29 23:30 +0100 |
| Message-ID | <qWpIe-1q3-3@gated-at.bofh.it> |
| In reply to | #1321077 |
On Thu, Jan 28, 2016 at 1:33 PM, Johannes Weiner <hannes@cmpxchg.org> wrote: > On Wed, Jan 27, 2016 at 12:32:16PM -0800, Andy Lutomirski wrote: >> On Wed, Jan 27, 2016 at 11:39 AM, Johannes Weiner <hannes@cmpxchg.org> wrote: >> > Could the VDSO be a VM_MIXEDMAP to keep the initial unmanaged pages >> > out of the VM while allowing COW into regular anonymous pages? >> >> Probably. What are its limitations? We want ptrace to work on it, >> and mprotect needs to work and allow COW. access_process_vm should >> probably work, too. > > Thanks, that's good to know. > > However, after looking at this a little longer, it appears this would > need work in do_wp_page() to support non-page COW copying, then adding > vm_ops->access and complicating ->fault in all VDSO implementations. > > And it looks like - at least theoretically - drivers can inject non-VM > pages into the page tables as well (comment above insert_page()) > > Given that this behavior has been around for a long time (the comment > at the bottom of vm_normal_page is ancient), I'll probably go with a > more conservative approach; add a comment to mark_page_accessed() and > filter out non-VM pages in the function I'm going to call from it. I just checked: in -tip, I'm creating a VM_PFNMAP (not VM_MIXEDMAP) vma and faulting a RAM page (with struct page and all) in using vm_insert_pfn. Is that okay, or so I need to use VM_MIXEDMAP instead? --Andy
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web