From: Michal Hocko <mhocko@kernel.org>
To: Jerome Glisse <jglisse@redhat.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Andrew Morton <akpm@linux-foundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
Date: Mon, 27 Aug 2018 21:09:20 +0200 [thread overview]
Message-ID: <20180827190850.GF21556@dhcp22.suse.cz> (raw)
In-Reply-To: <20180827134633.GB3930@redhat.com>
On Mon 27-08-18 09:46:33, Jerome Glisse wrote:
> On Mon, Aug 27, 2018 at 09:46:45AM +0200, Michal Hocko wrote:
> > On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
> > > On 08/24/2018 01:41 AM, Michal Hocko wrote:
> > > > On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
> > > >
> > > > Acked-by: Michal Hocko <mhocko@suse.com>
> > > >
> > > > One nit below.
> > > >
> > > > [...]
> > > >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > >> index 3103099f64fd..a73c5728e961 100644
> > > >> --- a/mm/hugetlb.c
> > > >> +++ b/mm/hugetlb.c
> > > >> @@ -4548,6 +4548,9 @@ static unsigned long page_table_shareable(struct vm_area_struct *svma,
> > > >> return saddr;
> > > >> }
> > > >>
> > > >> +#define _range_in_vma(vma, start, end) \
> > > >> + ((vma)->vm_start <= (start) && (end) <= (vma)->vm_end)
> > > >> +
> > > >
> > > > static inline please. Macros and potential side effects on given
> > > > arguments are just not worth the risk. I also think this is something
> > > > for more general use. We have that pattern at many places. So I would
> > > > stick that to linux/mm.h
> > >
> > > Thanks Michal,
> > >
> > > Here is an updated patch which does as you suggest above.
> > [...]
> > > @@ -1409,6 +1419,32 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
> > > subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
> > > address = pvmw.address;
> > >
> > > + if (PageHuge(page)) {
> > > + if (huge_pmd_unshare(mm, &address, pvmw.pte)) {
> > > + /*
> > > + * huge_pmd_unshare unmapped an entire PMD
> > > + * page. There is no way of knowing exactly
> > > + * which PMDs may be cached for this mm, so
> > > + * we must flush them all. start/end were
> > > + * already adjusted above to cover this range.
> > > + */
> > > + flush_cache_range(vma, start, end);
> > > + flush_tlb_range(vma, start, end);
> > > + mmu_notifier_invalidate_range(mm, start, end);
> > > +
> > > + /*
> > > + * The ref count of the PMD page was dropped
> > > + * which is part of the way map counting
> > > + * is done for shared PMDs. Return 'true'
> > > + * here. When there is no other sharing,
> > > + * huge_pmd_unshare returns false and we will
> > > + * unmap the actual page and drop map count
> > > + * to zero.
> > > + */
> > > + page_vma_mapped_walk_done(&pvmw);
> > > + break;
> > > + }
> >
> > This still calls into notifier while holding the ptl lock. Either I am
> > missing something or the invalidation is broken in this loop (not also
> > for other invalidations).
>
> mmu_notifier_invalidate_range() is done with pt lock held only the start
> and end versions need to happen outside pt lock.
OK, that was not clear to me. Especially srcu_read_lock in
__mmu_notifier_invalidate_range suggests the callback might sleep. There
is no note about the pte lock. There is even a note about possible
blocking
* If this callback cannot block, and invalidate_range_{start,end}
* cannot block, mmu_notifier_ops.flags should have
* MMU_INVALIDATE_DOES_NOT_BLOCK set.
I am removing that part of the comment but it really confused me.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-08-27 19:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-23 20:59 [PATCH v6 0/2] huge_pmd_unshare migration and flushing Mike Kravetz
2018-08-23 20:59 ` [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages Mike Kravetz
2018-08-24 2:59 ` Naoya Horiguchi
2018-08-24 8:41 ` Michal Hocko
2018-08-24 18:08 ` Mike Kravetz
2018-08-27 7:46 ` Michal Hocko
2018-08-27 13:46 ` Jerome Glisse
2018-08-27 19:09 ` Michal Hocko [this message]
2018-08-29 17:24 ` Mike Kravetz
2018-08-29 18:14 ` Jerome Glisse
2018-08-29 18:39 ` Michal Hocko
2018-08-29 21:11 ` Jerome Glisse
2018-08-30 0:40 ` Mike Kravetz
2018-08-30 10:56 ` Michal Hocko
2018-08-30 14:08 ` Jerome Glisse
2018-08-30 16:19 ` Michal Hocko
2018-08-30 16:57 ` Jerome Glisse
2018-08-30 18:05 ` Mike Kravetz
2018-08-30 18:39 ` Jerome Glisse
2018-09-03 5:56 ` Michal Hocko
2018-09-04 14:00 ` Jerome Glisse
2018-09-04 17:55 ` Mike Kravetz
2018-09-05 6:57 ` Michal Hocko
2018-08-27 16:42 ` Mike Kravetz
2018-08-27 19:11 ` Michal Hocko
2018-08-24 9:25 ` Michal Hocko
2018-08-23 20:59 ` [PATCH v6 2/2] hugetlb: take PMD sharing into account when flushing tlb/caches Mike Kravetz
2018-08-24 3:07 ` Naoya Horiguchi
2018-08-24 11:35 ` [PATCH v6 0/2] huge_pmd_unshare migration and flushing Kirill A. Shutemov
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=20180827190850.GF21556@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
/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