* [PATCH 0/2] mm: khugepaged: cleanup and a minor tuning in THP @ 2021-04-04 15:33 yanfei.xu 2021-04-04 15:33 ` [PATCH 1/2] mm: khugepaged: use macro to align addresses yanfei.xu 2021-04-04 15:33 ` [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas yanfei.xu 0 siblings, 2 replies; 7+ messages in thread From: yanfei.xu @ 2021-04-04 15:33 UTC (permalink / raw) To: linux-mm, linux-kernel From: Yanfei Xu <yanfei.xu@windriver.com> Yanfei Xu (2): mm: khugepaged: use macro to align addresses mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas mm/khugepaged.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) -- 2.27.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/2] mm: khugepaged: use macro to align addresses 2021-04-04 15:33 [PATCH 0/2] mm: khugepaged: cleanup and a minor tuning in THP yanfei.xu @ 2021-04-04 15:33 ` yanfei.xu 2021-04-04 15:33 ` [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas yanfei.xu 1 sibling, 0 replies; 7+ messages in thread From: yanfei.xu @ 2021-04-04 15:33 UTC (permalink / raw) To: linux-mm, linux-kernel From: Yanfei Xu <yanfei.xu@windriver.com> We could use macro to deal with the addresses which need to be aligned to improve readability of codes. Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> --- mm/khugepaged.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index a7d6cb912b05..2efe1d0c92ed 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -517,8 +517,8 @@ int khugepaged_enter_vma_merge(struct vm_area_struct *vma, if (!hugepage_vma_check(vma, vm_flags)) return 0; - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; - hend = vma->vm_end & HPAGE_PMD_MASK; + hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); + hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); if (hstart < hend) return khugepaged_enter(vma, vm_flags); return 0; @@ -979,8 +979,8 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address, if (!vma) return SCAN_VMA_NULL; - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; - hend = vma->vm_end & HPAGE_PMD_MASK; + hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); + hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); if (address < hstart || address + HPAGE_PMD_SIZE > hend) return SCAN_ADDRESS_RANGE; if (!hugepage_vma_check(vma, vma->vm_flags)) @@ -1070,7 +1070,7 @@ static void collapse_huge_page(struct mm_struct *mm, struct mmu_notifier_range range; gfp_t gfp; - VM_BUG_ON(address & ~HPAGE_PMD_MASK); + VM_BUG_ON(!IS_ALIGNED(address, HPAGE_PMD_SIZE)); /* Only allocate from the target node */ gfp = alloc_hugepage_khugepaged_gfpmask() | __GFP_THISNODE; @@ -1235,7 +1235,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm, int node = NUMA_NO_NODE, unmapped = 0; bool writable = false; - VM_BUG_ON(address & ~HPAGE_PMD_MASK); + VM_BUG_ON(!IS_ALIGNED(address, HPAGE_PMD_SIZE)); pmd = mm_find_pmd(mm, address); if (!pmd) { @@ -1414,7 +1414,7 @@ static int khugepaged_add_pte_mapped_thp(struct mm_struct *mm, { struct mm_slot *mm_slot; - VM_BUG_ON(addr & ~HPAGE_PMD_MASK); + VM_BUG_ON(!IS_ALIGNED(addr, HPAGE_PMD_SIZE)); spin_lock(&khugepaged_mm_lock); mm_slot = get_mm_slot(mm); @@ -1437,7 +1437,7 @@ static int khugepaged_add_pte_mapped_thp(struct mm_struct *mm, */ void collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr) { - unsigned long haddr = addr & HPAGE_PMD_MASK; + unsigned long haddr = ALIGN_DOWN(addr, HPAGE_PMD_SIZE); struct vm_area_struct *vma = find_vma(mm, haddr); struct page *hpage; pte_t *start_pte, *pte; @@ -1584,7 +1584,7 @@ static void retract_page_tables(struct address_space *mapping, pgoff_t pgoff) if (vma->anon_vma) continue; addr = vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT); - if (addr & ~HPAGE_PMD_MASK) + if (!IS_ALIGNED(addr, HPAGE_PMD_SIZE)) continue; if (vma->vm_end < addr + HPAGE_PMD_SIZE) continue; @@ -2070,7 +2070,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, { struct mm_slot *mm_slot; struct mm_struct *mm; - struct vm_area_struct *vma; + struct vm_area_struct *vma = NULL; int progress = 0; VM_BUG_ON(!pages); @@ -2092,7 +2092,6 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, * Don't wait for semaphore (to avoid long wait times). Just move to * the next mm on the list. */ - vma = NULL; if (unlikely(!mmap_read_trylock(mm))) goto breakouterloop_mmap_lock; if (likely(!khugepaged_test_exit(mm))) @@ -2112,15 +2111,16 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, progress++; continue; } - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; - hend = vma->vm_end & HPAGE_PMD_MASK; + hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); + hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); if (hstart >= hend) goto skip; if (khugepaged_scan.address > hend) goto skip; if (khugepaged_scan.address < hstart) khugepaged_scan.address = hstart; - VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK); + VM_BUG_ON(!IS_ALIGNED(khugepaged_scan.address, HPAGE_PMD_SIZE)); + if (shmem_file(vma->vm_file) && !shmem_huge_enabled(vma)) goto skip; -- 2.27.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas 2021-04-04 15:33 [PATCH 0/2] mm: khugepaged: cleanup and a minor tuning in THP yanfei.xu 2021-04-04 15:33 ` [PATCH 1/2] mm: khugepaged: use macro to align addresses yanfei.xu @ 2021-04-04 15:33 ` yanfei.xu 2021-04-05 18:20 ` Yang Shi 1 sibling, 1 reply; 7+ messages in thread From: yanfei.xu @ 2021-04-04 15:33 UTC (permalink / raw) To: linux-mm, linux-kernel From: Yanfei Xu <yanfei.xu@windriver.com> We could check MMF_DISABLE_THP ahead of iterating over all of vma. Otherwise if some mm_struct contain a large number of vma, there will be amounts meaningless cpu cycles cost. BTW, drop an unnecessary cond_resched(), because there is a another cond_resched() followed it and no consumed invocation between them. Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> --- mm/khugepaged.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 2efe1d0c92ed..c293ec4a94ea 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -2094,6 +2094,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, */ if (unlikely(!mmap_read_trylock(mm))) goto breakouterloop_mmap_lock; + if (test_bit(MMF_DISABLE_THP, &mm->flags)) + goto breakouterloop_mmap_lock; if (likely(!khugepaged_test_exit(mm))) vma = find_vma(mm, khugepaged_scan.address); @@ -2101,7 +2103,6 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, for (; vma; vma = vma->vm_next) { unsigned long hstart, hend; - cond_resched(); if (unlikely(khugepaged_test_exit(mm))) { progress++; break; -- 2.27.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas 2021-04-04 15:33 ` [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas yanfei.xu @ 2021-04-05 18:20 ` Yang Shi 2021-04-06 2:51 ` Xu, Yanfei 0 siblings, 1 reply; 7+ messages in thread From: Yang Shi @ 2021-04-05 18:20 UTC (permalink / raw) To: yanfei.xu; +Cc: Linux MM, Linux Kernel Mailing List On Sun, Apr 4, 2021 at 8:33 AM <yanfei.xu@windriver.com> wrote: > > From: Yanfei Xu <yanfei.xu@windriver.com> > > We could check MMF_DISABLE_THP ahead of iterating over all of vma. > Otherwise if some mm_struct contain a large number of vma, there will > be amounts meaningless cpu cycles cost. > > BTW, drop an unnecessary cond_resched(), because there is a another > cond_resched() followed it and no consumed invocation between them. > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > --- > mm/khugepaged.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 2efe1d0c92ed..c293ec4a94ea 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -2094,6 +2094,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, > */ > if (unlikely(!mmap_read_trylock(mm))) > goto breakouterloop_mmap_lock; > + if (test_bit(MMF_DISABLE_THP, &mm->flags)) > + goto breakouterloop_mmap_lock; It is fine to check this flag. But mmap_lock has been acquired so you should jump to breakouterloop. > if (likely(!khugepaged_test_exit(mm))) > vma = find_vma(mm, khugepaged_scan.address); > > @@ -2101,7 +2103,6 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, > for (; vma; vma = vma->vm_next) { > unsigned long hstart, hend; > > - cond_resched(); I don't have a strong opinion for removing this cond_resched(). But IIUC khugepaged is a best effort job there is no harm to keep it IMHO. > if (unlikely(khugepaged_test_exit(mm))) { > progress++; > break; > -- > 2.27.0 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas 2021-04-05 18:20 ` Yang Shi @ 2021-04-06 2:51 ` Xu, Yanfei 2021-04-06 3:04 ` Xu, Yanfei 0 siblings, 1 reply; 7+ messages in thread From: Xu, Yanfei @ 2021-04-06 2:51 UTC (permalink / raw) To: Yang Shi; +Cc: Linux MM, Linux Kernel Mailing List On 4/6/21 2:20 AM, Yang Shi wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > On Sun, Apr 4, 2021 at 8:33 AM <yanfei.xu@windriver.com> wrote: >> >> From: Yanfei Xu <yanfei.xu@windriver.com> >> >> We could check MMF_DISABLE_THP ahead of iterating over all of vma. >> Otherwise if some mm_struct contain a large number of vma, there will >> be amounts meaningless cpu cycles cost. >> >> BTW, drop an unnecessary cond_resched(), because there is a another >> cond_resched() followed it and no consumed invocation between them. >> >> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >> --- >> mm/khugepaged.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >> index 2efe1d0c92ed..c293ec4a94ea 100644 >> --- a/mm/khugepaged.c >> +++ b/mm/khugepaged.c >> @@ -2094,6 +2094,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, >> */ >> if (unlikely(!mmap_read_trylock(mm))) >> goto breakouterloop_mmap_lock; >> + if (test_bit(MMF_DISABLE_THP, &mm->flags)) >> + goto breakouterloop_mmap_lock; > > It is fine to check this flag. But mmap_lock has been acquired so you > should jump to breakouterloop. Oops! It's my fault. Thank you for pointing out this. Will fix it in v2. > >> if (likely(!khugepaged_test_exit(mm))) >> vma = find_vma(mm, khugepaged_scan.address); >> >> @@ -2101,7 +2103,6 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, >> for (; vma; vma = vma->vm_next) { >> unsigned long hstart, hend; >> >> - cond_resched(); > > I don't have a strong opinion for removing this cond_resched(). But > IIUC khugepaged is a best effort job there is no harm to keep it IMHO. > Yes, keeping it is no harm. But I think we should add it when we need. Look at the blow codes, there are only some simple check between these two cond_resched(). And we still have some cond_resched() in the khugepaged_scan_file() and khugepaged_scan_pmd() which is the actual wrok about collapsing. So I think it is unnecessary. :) for (; vma; vma = vma->vm_next) { unsigned long hstart, hend; cond_resched(); //here if (unlikely(khugepaged_test_exit(mm))) { progress++; break; } if (!hugepage_vma_check(vma, vma->vm_flags)) { skip: progress++; continue; } hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); if (hstart >= hend) goto skip; if (khugepaged_scan.address > hend) goto skip; if (khugepaged_scan.address < hstart) khugepaged_scan.address = hstart; VM_BUG_ON(!IS_ALIGNED(khugepaged_scan.address, HPAGE_PMD_SIZE)); if (shmem_file(vma->vm_file) && !shmem_huge_enabled(vma)) goto skip; while (khugepaged_scan.address < hend) { int ret; cond_resched(); //here >> if (unlikely(khugepaged_test_exit(mm))) { >> progress++; >> break; >> -- >> 2.27.0 >> >> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas 2021-04-06 2:51 ` Xu, Yanfei @ 2021-04-06 3:04 ` Xu, Yanfei 2021-04-06 21:04 ` Yang Shi 0 siblings, 1 reply; 7+ messages in thread From: Xu, Yanfei @ 2021-04-06 3:04 UTC (permalink / raw) To: Yang Shi; +Cc: Linux MM, Linux Kernel Mailing List On 4/6/21 10:51 AM, Xu, Yanfei wrote: > > > On 4/6/21 2:20 AM, Yang Shi wrote: >> [Please note: This e-mail is from an EXTERNAL e-mail address] >> >> On Sun, Apr 4, 2021 at 8:33 AM <yanfei.xu@windriver.com> wrote: >>> >>> From: Yanfei Xu <yanfei.xu@windriver.com> >>> >>> We could check MMF_DISABLE_THP ahead of iterating over all of vma. >>> Otherwise if some mm_struct contain a large number of vma, there will >>> be amounts meaningless cpu cycles cost. >>> >>> BTW, drop an unnecessary cond_resched(), because there is a another >>> cond_resched() followed it and no consumed invocation between them. >>> >>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>> --- >>> mm/khugepaged.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >>> index 2efe1d0c92ed..c293ec4a94ea 100644 >>> --- a/mm/khugepaged.c >>> +++ b/mm/khugepaged.c >>> @@ -2094,6 +2094,8 @@ static unsigned int >>> khugepaged_scan_mm_slot(unsigned int pages, >>> */ >>> if (unlikely(!mmap_read_trylock(mm))) >>> goto breakouterloop_mmap_lock; >>> + if (test_bit(MMF_DISABLE_THP, &mm->flags)) >>> + goto breakouterloop_mmap_lock; >> >> It is fine to check this flag. But mmap_lock has been acquired so you >> should jump to breakouterloop. > > Oops! It's my fault. Thank you for pointing out this. > Will fix it in v2. > >> >>> if (likely(!khugepaged_test_exit(mm))) >>> vma = find_vma(mm, khugepaged_scan.address); >>> >>> @@ -2101,7 +2103,6 @@ static unsigned int >>> khugepaged_scan_mm_slot(unsigned int pages, >>> for (; vma; vma = vma->vm_next) { >>> unsigned long hstart, hend; >>> >>> - cond_resched(); >> >> I don't have a strong opinion for removing this cond_resched(). But >> IIUC khugepaged is a best effort job there is no harm to keep it IMHO. >> > > Yes, keeping it is no harm. But I think we should add it when we need. > Look at the blow codes, there are only some simple check between these > two cond_resched(). And we still have some cond_resched() in the > khugepaged_scan_file() and khugepaged_scan_pmd() which is the actual > wrok about collapsing. So I think it is unnecessary. :) > BTW, the original author add this cond_resched() might be worry about the hugepage_vma_check() always return false due to the MMF_DISABLE_THP. But now we have moved it out of the for loop of iterating vma. um.. That is my guess.. Thanks, Yanfei > for (; vma; vma = vma->vm_next) { > unsigned long hstart, hend; > > cond_resched(); //here > if (unlikely(khugepaged_test_exit(mm))) { > progress++; > break; > } > if (!hugepage_vma_check(vma, vma->vm_flags)) { > skip: > progress++; > continue; > } > hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); > hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); > if (hstart >= hend) > goto skip; > if (khugepaged_scan.address > hend) > goto skip; > if (khugepaged_scan.address < hstart) > khugepaged_scan.address = hstart; > VM_BUG_ON(!IS_ALIGNED(khugepaged_scan.address, > HPAGE_PMD_SIZE)); > > if (shmem_file(vma->vm_file) && !shmem_huge_enabled(vma)) > goto skip; > > while (khugepaged_scan.address < hend) { > int ret; > cond_resched(); //here > > >>> if (unlikely(khugepaged_test_exit(mm))) { >>> progress++; >>> break; >>> -- >>> 2.27.0 >>> >>> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas 2021-04-06 3:04 ` Xu, Yanfei @ 2021-04-06 21:04 ` Yang Shi 0 siblings, 0 replies; 7+ messages in thread From: Yang Shi @ 2021-04-06 21:04 UTC (permalink / raw) To: Xu, Yanfei; +Cc: Linux MM, Linux Kernel Mailing List On Mon, Apr 5, 2021 at 8:05 PM Xu, Yanfei <yanfei.xu@windriver.com> wrote: > > > > On 4/6/21 10:51 AM, Xu, Yanfei wrote: > > > > > > On 4/6/21 2:20 AM, Yang Shi wrote: > >> [Please note: This e-mail is from an EXTERNAL e-mail address] > >> > >> On Sun, Apr 4, 2021 at 8:33 AM <yanfei.xu@windriver.com> wrote: > >>> > >>> From: Yanfei Xu <yanfei.xu@windriver.com> > >>> > >>> We could check MMF_DISABLE_THP ahead of iterating over all of vma. > >>> Otherwise if some mm_struct contain a large number of vma, there will > >>> be amounts meaningless cpu cycles cost. > >>> > >>> BTW, drop an unnecessary cond_resched(), because there is a another > >>> cond_resched() followed it and no consumed invocation between them. > >>> > >>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > >>> --- > >>> mm/khugepaged.c | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c > >>> index 2efe1d0c92ed..c293ec4a94ea 100644 > >>> --- a/mm/khugepaged.c > >>> +++ b/mm/khugepaged.c > >>> @@ -2094,6 +2094,8 @@ static unsigned int > >>> khugepaged_scan_mm_slot(unsigned int pages, > >>> */ > >>> if (unlikely(!mmap_read_trylock(mm))) > >>> goto breakouterloop_mmap_lock; > >>> + if (test_bit(MMF_DISABLE_THP, &mm->flags)) > >>> + goto breakouterloop_mmap_lock; > >> > >> It is fine to check this flag. But mmap_lock has been acquired so you > >> should jump to breakouterloop. > > > > Oops! It's my fault. Thank you for pointing out this. > > Will fix it in v2. > > > >> > >>> if (likely(!khugepaged_test_exit(mm))) > >>> vma = find_vma(mm, khugepaged_scan.address); > >>> > >>> @@ -2101,7 +2103,6 @@ static unsigned int > >>> khugepaged_scan_mm_slot(unsigned int pages, > >>> for (; vma; vma = vma->vm_next) { > >>> unsigned long hstart, hend; > >>> > >>> - cond_resched(); > >> > >> I don't have a strong opinion for removing this cond_resched(). But > >> IIUC khugepaged is a best effort job there is no harm to keep it IMHO. > >> > > > > Yes, keeping it is no harm. But I think we should add it when we need. > > Look at the blow codes, there are only some simple check between these > > two cond_resched(). And we still have some cond_resched() in the > > khugepaged_scan_file() and khugepaged_scan_pmd() which is the actual > > wrok about collapsing. So I think it is unnecessary. :) > > > > BTW, the original author add this cond_resched() might be worry about > the hugepage_vma_check() always return false due to the MMF_DISABLE_THP. > But now we have moved it out of the for loop of iterating vma. A little bit of archeology showed the cond_resched() was there in the first place even before MMF_DISABLE_THP was introduced. > > um.. That is my guess.. > > Thanks, > Yanfei > > > for (; vma; vma = vma->vm_next) { > > unsigned long hstart, hend; > > > > cond_resched(); //here > > if (unlikely(khugepaged_test_exit(mm))) { > > progress++; > > break; > > } > > if (!hugepage_vma_check(vma, vma->vm_flags)) { > > skip: > > progress++; > > continue; > > } > > hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); > > hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); > > if (hstart >= hend) > > goto skip; > > if (khugepaged_scan.address > hend) > > goto skip; > > if (khugepaged_scan.address < hstart) > > khugepaged_scan.address = hstart; > > VM_BUG_ON(!IS_ALIGNED(khugepaged_scan.address, > > HPAGE_PMD_SIZE)); > > > > if (shmem_file(vma->vm_file) && !shmem_huge_enabled(vma)) > > goto skip; > > > > while (khugepaged_scan.address < hend) { > > int ret; > > cond_resched(); //here > > > > > >>> if (unlikely(khugepaged_test_exit(mm))) { > >>> progress++; > >>> break; > >>> -- > >>> 2.27.0 > >>> > >>> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-06 21:05 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-04 15:33 [PATCH 0/2] mm: khugepaged: cleanup and a minor tuning in THP yanfei.xu 2021-04-04 15:33 ` [PATCH 1/2] mm: khugepaged: use macro to align addresses yanfei.xu 2021-04-04 15:33 ` [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas yanfei.xu 2021-04-05 18:20 ` Yang Shi 2021-04-06 2:51 ` Xu, Yanfei 2021-04-06 3:04 ` Xu, Yanfei 2021-04-06 21:04 ` Yang Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).