From: Mike Kravetz <mike.kravetz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
"Jérôme Glisse" <jglisse@redhat.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:42:03 -0700 [thread overview]
Message-ID: <3d9057ef-13ad-7796-ebb0-f86cf7936127@oracle.com> (raw)
In-Reply-To: <20180827074645.GB21556@dhcp22.suse.cz>
On 08/27/2018 12:46 AM, 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).
As Jerome said ...
When creating this patch, I started by using the same flush/invalidation
routines used by the existing code. This is because it is not obvious what
interfaces can be called in what context, and I didn't want to do anything
different. The best 'documentation' are the comments in the mmu_notifier_ops
definition.
--
Mike Kravetz
next prev parent reply other threads:[~2018-08-27 16:42 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
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 [this message]
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=3d9057ef-13ad-7796-ebb0-f86cf7936127@oracle.com \
--to=mike.kravetz@oracle.com \
--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=mhocko@kernel.org \
--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