On 7 Aug 2021, at 6:32, Mike Rapoport wrote: > On Thu, Aug 05, 2021 at 03:02:46PM -0400, Zi Yan wrote: >> From: Zi Yan >> >> It keeps the existing behavior after MAX_ORDER is increased beyond >> a section size. >> >> Signed-off-by: Zi Yan >> Cc: Mike Rapoport >> Cc: David Hildenbrand >> Cc: Oscar Salvador >> Cc: Ying Chen >> Cc: Feng Zhou >> Cc: linux-fsdevel@vger.kernel.org >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> fs/proc/kcore.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c >> index 3f148759a5fd..77b7ba48fb44 100644 >> --- a/fs/proc/kcore.c >> +++ b/fs/proc/kcore.c >> @@ -486,7 +486,7 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos) >> } >> } >> >> - if (page_offline_frozen++ % MAX_ORDER_NR_PAGES == 0) { >> + if (page_offline_frozen++ % PAGES_PER_SECTION == 0) { > > The behavior changes here. E.g. with default configuration on x86 instead > of cond_resched() every 2M we get cond_resched() every 128M. > > I'm not saying it's wrong but at least it deserves an explanation why. Sure. I will also think about whether I should use PAGES_PER_SECTION or pageblock_nr_pages to replace MAX_ORDER in this and other patches. pageblock_nr_pages will be unchanged, so at least in x86_64, using pageblock_nr_pages would not change code behaviors. — Best Regards, Yan, Zi