From: Jerome Glisse <jglisse@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
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 09:46:33 -0400 [thread overview]
Message-ID: <20180827134633.GB3930@redhat.com> (raw)
In-Reply-To: <20180827074645.GB21556@dhcp22.suse.cz>
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.
Cheers,
Jerome
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
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 09:46:33 -0400 [thread overview]
Message-ID: <20180827134633.GB3930@redhat.com> (raw)
In-Reply-To: <20180827074645.GB21556@dhcp22.suse.cz>
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.
Cheers,
Jérôme
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
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 09:46:33 -0400 [thread overview]
Message-ID: <20180827134633.GB3930@redhat.com> (raw)
In-Reply-To: <20180827074645.GB21556@dhcp22.suse.cz>
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.
Cheers,
J�r�me
next prev parent reply other threads:[~2018-08-27 13:46 UTC|newest]
Thread overview: 49+ 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 [this message]
2018-08-27 13:46 ` Jerome Glisse
2018-08-27 13:46 ` Jerome Glisse
2018-08-27 19:09 ` Michal Hocko
2018-08-29 17:24 ` Mike Kravetz
2018-08-29 17:24 ` Mike Kravetz
2018-08-29 18:14 ` Jerome Glisse
2018-08-29 18:14 ` Jerome Glisse
2018-08-29 18:14 ` Jerome Glisse
2018-08-29 18:39 ` Michal Hocko
2018-08-29 21:11 ` Jerome Glisse
2018-08-29 21:11 ` Jerome Glisse
2018-08-29 21:11 ` Jerome Glisse
2018-08-30 0:40 ` Mike Kravetz
2018-08-30 10:56 ` Michal Hocko
2018-08-30 10:56 ` Michal Hocko
2018-08-30 10:56 ` Michal Hocko
2018-08-30 14:08 ` Jerome Glisse
2018-08-30 14:08 ` Jerome Glisse
2018-08-30 14:08 ` Jerome Glisse
2018-08-30 16:19 ` Michal Hocko
2018-08-30 16:19 ` Michal Hocko
2018-08-30 16:19 ` Michal Hocko
2018-08-30 16:57 ` Jerome Glisse
2018-08-30 16:57 ` Jerome Glisse
2018-08-30 18:05 ` Mike Kravetz
2018-08-30 18:05 ` Mike Kravetz
2018-08-30 18:39 ` Jerome Glisse
2018-08-30 18:39 ` Jerome Glisse
2018-08-30 18:39 ` Jerome Glisse
2018-09-03 5:56 ` Michal Hocko
2018-09-04 14:00 ` Jerome Glisse
2018-09-04 14:00 ` Jerome Glisse
2018-09-04 14:00 ` Jerome Glisse
2018-09-04 17:55 ` Mike Kravetz
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=20180827134633.GB3930@redhat.com \
--to=jglisse@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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 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.