From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges
Date: Thu, 26 Sep 2019 15:20:42 -0700 [thread overview]
Message-ID: <CAHk-=wh_+Co=T8wG8vb5akMP=7H4BN=Qpq6PsKh8rcmT8MCV+Q@mail.gmail.com> (raw)
In-Reply-To: <c58cdb3d-4f5e-7bfc-06b3-58c27676d101@shipmail.org>
On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> Well, we're working on supporting huge puds and pmds in the graphics
> VMAs, although in the write-notify cases we're looking at here, we would
> probably want to split them down to PTE level.
Well, that's what the existing walker code does if you don't have that
"pud_entry()" callback.
That said, I assume you would *not* want to do that if the huge
pud/pmd is already clean and read-only, but just continue.
So you may want to have a special pud_entry() that handles that case.
Eventually. Maybe. Although honestly, if you're doing dirty tracking,
I doubt it makes much sense to use largepages.
> Looking at zap_pud_range() which when called from unmap_mapping_pages()
> uses identical locking (no mmap_sem), it seems we should be able to get
> away with i_mmap_lock(), making sure the whole page table doesn't
> disappear under us. So it's not clear to me why the mmap_sem is strictly
> needed here. Better to sort those restrictions out now rather than when
> huge entries start appearing.
zap_pud_range()actually does have that
VM_BUG_ON_VMA(!rwsem_is_locked(&tlb->mm->mmap_sem), vma);
exactly for the case where it might have to split the pud entry.
Zapping the whole thing it does do without the assert.
I'm not going to swear the mmap_sem is absolutely required, since a
shared vma should be stable due to the i_mmap_lock, but splitting the
hugepage really is a fairly big deal.
It can't happen if you zap the *whole* mapping, but it can happen if
you have a start/end range. Like you do.
Also, in general it's probably not a great idea to look at
zap_page_range() (and copy_page_range()) for ideas.
They are kind of special, since they tend to be used for fundamental
whole-address-space operations (ie fork/exit) and so as a result they
get to do special things that a normal page walker generally shouldn't
do.
It's why they've never gotten translated to use the generic walker code.
Linus
next prev parent reply other threads:[~2019-09-26 22:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 11:55 [PATCH v2 0/5] Emulated coherent graphics memory take 2 Thomas Hellström (VMware)
2019-09-26 11:55 ` [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges Thomas Hellström (VMware)
2019-09-26 12:03 ` Ack to merge through DRM? WAS " Thomas Hellström (VMware)
2019-09-26 19:19 ` Linus Torvalds
2019-09-26 20:09 ` Thomas Hellström (VMware)
2019-09-26 20:16 ` Linus Torvalds
2019-09-26 20:55 ` Thomas Hellström (VMware)
2019-09-26 22:20 ` Linus Torvalds [this message]
2019-09-27 5:55 ` Thomas Hellström (VMware)
2019-09-27 9:27 ` Thomas Hellström (VMware)
2019-09-27 12:26 ` Kirill A. Shutemov
2019-09-27 12:17 ` Kirill A. Shutemov
2019-09-27 16:39 ` Linus Torvalds
2019-09-30 13:03 ` Kirill A. Shutemov
2019-09-30 17:12 ` Linus Torvalds
2019-09-30 17:38 ` Thomas Hellström (VMware)
2019-10-02 9:21 ` Thomas Hellström (VMware)
2019-10-02 13:18 ` Kirill A. Shutemov
2019-10-02 13:28 ` Thomas Hellström (VMware)
2019-09-26 11:55 ` [PATCH v2 2/5] drm/vmwgfx: Implement an infrastructure for write-coherent resources Thomas Hellström (VMware)
2019-09-26 11:55 ` [PATCH v2 3/5] drm/vmwgfx: Use an RBtree instead of linked list for MOB resources Thomas Hellström (VMware)
2019-09-26 11:55 ` [PATCH v2 4/5] drm/vmwgfx: Implement an infrastructure for read-coherent resources Thomas Hellström (VMware)
2019-09-26 11:55 ` [PATCH v2 5/5] drm/vmwgfx: Add surface dirty-tracking callbacks Thomas Hellström (VMware)
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='CAHk-=wh_+Co=T8wG8vb5akMP=7H4BN=Qpq6PsKh8rcmT8MCV+Q@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=thomas_os@shipmail.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).