From: Larry Bassel <larry.bassel@oracle.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Larry Bassel <larry.bassel@oracle.com>,
mike.kravetz@oracle.com, dan.j.williams@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org
Subject: Re: [PATCH, RFC 2/2] Implement sharing/unsharing of PMDs for FS/DAX
Date: Fri, 10 May 2019 09:16:07 -0700 [thread overview]
Message-ID: <20190510161607.GB27674@ubuette> (raw)
In-Reply-To: <20190509164914.GA3862@bombadil.infradead.org>
On 09 May 19 09:49, Matthew Wilcox wrote:
> On Thu, May 09, 2019 at 09:05:33AM -0700, Larry Bassel wrote:
> > This is based on (but somewhat different from) what hugetlbfs
> > does to share/unshare page tables.
>
> Wow, that worked out far more cleanly than I was expecting to see.
Yes, I was pleasantly surprised. As I've mentioned already, I
think this is at least partially due to the nature of DAX.
>
> > @@ -4763,6 +4763,19 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
> > unsigned long *start, unsigned long *end)
> > {
> > }
> > +
> > +unsigned long page_table_shareable(struct vm_area_struct *svma,
> > + struct vm_area_struct *vma,
> > + unsigned long addr, pgoff_t idx)
> > +{
> > + return 0;
> > +}
> > +
> > +bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
> > +{
> > + return false;
> > +}
>
> I don't think you need these stubs, since the only caller of them is
> also gated by MAY_SHARE_FSDAX_PMD ... right?
These are also called in mm/hugetlb.c, but those calls are gated by
CONFIG_ARCH_WANT_HUGE_PMD_SHARE. In fact if this is not set (though
it is the default), then one wouldn't get FS/DAX sharing even if
MAY_SHARE_FSDAX_PMD is set. I think that this isn't what we want
(perhaps the real question is how should these two config options interact?).
Removing the stubs would fix this and I will make that change.
Maybe these two functions should be moved into mm/memory.c as well.
>
> > + vma_interval_tree_foreach(svma, &mapping->i_mmap, idx, idx) {
> > + if (svma == vma)
> > + continue;
> > +
> > + saddr = page_table_shareable(svma, vma, addr, idx);
> > + if (saddr) {
> > + spmd = huge_pmd_offset(svma->vm_mm, saddr,
> > + vma_mmu_pagesize(svma));
> > + if (spmd) {
> > + get_page(virt_to_page(spmd));
> > + break;
> > + }
> > + }
> > + }
>
> I'd be tempted to reduce the indentation here:
>
> vma_interval_tree_foreach(svma, &mapping->i_mmap, idx, idx) {
> if (svma == vma)
> continue;
>
> saddr = page_table_shareable(svma, vma, addr, idx);
> if (!saddr)
> continue;
>
> spmd = huge_pmd_offset(svma->vm_mm, saddr,
> vma_mmu_pagesize(svma));
> if (spmd)
> break;
> }
>
>
> > + if (!spmd)
> > + goto out;
>
> ... and move the get_page() down to here, so we don't split the
> "when we find it" logic between inside and outside the loop.
>
> get_page(virt_to_page(spmd));
>
> > +
> > + ptl = pmd_lockptr(mm, spmd);
> > + spin_lock(ptl);
> > +
> > + if (pud_none(*pud)) {
> > + pud_populate(mm, pud,
> > + (pmd_t *)((unsigned long)spmd & PAGE_MASK));
> > + mm_inc_nr_pmds(mm);
> > + } else {
> > + put_page(virt_to_page(spmd));
> > + }
> > + spin_unlock(ptl);
> > +out:
> > + pmd = pmd_alloc(mm, pud, addr);
> > + i_mmap_unlock_write(mapping);
>
> I would swap these two lines. There's no need to hold the i_mmap_lock
> while allocating this PMD, is there? I mean, we don't for the !may_share
> case.
>
These were done in the style of functions already in mm/hugetlb.c and I was
trying to change as little as necessary in my copy of those. I agree that
these are good suggestions. One could argue that if these changes
were made, they should also be made in mm/hugetlb.c, though
this is perhaps beyond the scope of getting FS/DAX PMD sharing
implemented -- your thoughts?
Thanks for the review, I'll wait a few more days for other comments
and then send out a v2.
Larry
next prev parent reply other threads:[~2019-05-10 16:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-09 16:05 [PATCH, RFC 0/2] Share PMDs for FS/DAX on x86 Larry Bassel
2019-05-09 16:05 ` [PATCH, RFC 1/2] Add config option to enable FS/DAX PMD sharing Larry Bassel
2019-05-10 16:32 ` Elliott, Robert (Servers)
2019-05-10 18:14 ` Dan Williams
2019-05-09 16:05 ` [PATCH, RFC 2/2] Implement sharing/unsharing of PMDs for FS/DAX Larry Bassel
2019-05-09 16:49 ` Matthew Wilcox
2019-05-10 16:16 ` Larry Bassel [this message]
2019-05-10 22:45 ` Mike Kravetz
2019-05-14 13:01 ` Kirill A. Shutemov
2019-05-24 16:07 ` Larry Bassel
2019-05-24 17:02 ` Dan Williams
2019-06-12 2:07 ` Kirill A. Shutemov
2019-05-14 12:28 ` [PATCH, RFC 0/2] Share PMDs for FS/DAX on x86 Kirill A. Shutemov
2019-05-14 16:09 ` Larry Bassel
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=20190510161607.GB27674@ubuette \
--to=larry.bassel@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mike.kravetz@oracle.com \
--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