lkml.org 
[lkml]   [2018]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages
On Thu 23-08-18 10:56:30, Mike Kravetz wrote:
> On 08/23/2018 10:01 AM, Mike Kravetz wrote:
> > On 08/23/2018 05:48 AM, Michal Hocko wrote:
> >> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> >> [...]
> >>
> >> OK, after burning myself when trying to be clever here it seems like
> >> your proposed solution is indeed simpler.
> >>
> >>> +bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
> >>> + unsigned long *start, unsigned long *end)
> >>> +{
> >>> + unsigned long check_addr = *start;
> >>> + bool ret = false;
> >>> +
> >>> + if (!(vma->vm_flags & VM_MAYSHARE))
> >>> + return ret;
> >>> +
> >>> + for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
> >>> + unsigned long a_start = check_addr & PUD_MASK;
> >>> + unsigned long a_end = a_start + PUD_SIZE;
> >>
> >> I guess this should be rather in HPAGE_SIZE * PTRS_PER_PTE units as
> >> huge_pmd_unshare does.
> >
> > Sure, I can do that.
>
> On second thought, this is more similar to vma_shareable() which uses
> PUD_MASK and PUD_SIZE. In fact Kirill asked me to put in a common helper
> for this and vma_shareable. So, I would prefer to leave it as PUD* unless
> you feel strongly.

I don't

> IMO, it would make more sense to change this in huge_pmd_unshare as PMD
> sharing is pretty explicitly tied to PUD_SIZE. But, that is a future cleanup.

Fair enough. I didn't realize we are PUD explicit elsewhere. So if you
plan to update huge_pmd_unshare to be in sync then no objections from me
at all. I merely wanted to be in sync with this because it is a central
point to look at wrt pmd sharing.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2018-08-23 21:36    [W:0.047 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site