From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BE4127280A for ; Tue, 24 Feb 2026 05:46:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771912013; cv=none; b=Yi0AT/LXTx2YWED174LAiYZK0A2XIXWTjIxXdS1Z/m37goFHOkiXiPP4JjQtyOd2EATNfUyRroi/ebnRtbOcfeBiqfSNXFm+1GA6Vb7VKSoEXrUnc1h+Sajp8+PGiF5V//JGQLw77ezA3chfSqKDV57OvCzGeekWwaVYrFQbUl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771912013; c=relaxed/simple; bh=a4+q7gcm+G8Lw2BwEYo00rzmAcCrnGlJSU2DU+ikWPo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QHpn9d2GC+tOlyh3RpiQbxgM5JeSKMby0Hdaflitbw/vb/2n//Zu1wHNW55s3k+GteCLwYEqSRcqF5PuwgS3A3fThG0AGZQAdaXbvRteNkSkl/qdhTofYAPcl4X7c5rSGbDgDMn0T5ObcVNaVU7uMiCfABGpXPN255gL31y2AHU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a94pNmMh; arc=none smtp.client-ip=209.85.218.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a94pNmMh" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-b884ad1026cso793514266b.2 for ; Mon, 23 Feb 2026 21:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771912010; x=1772516810; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=qNr8d1nrqZZDfnro4iFgBQlAdVfxjJDLWxz4pVReYn8=; b=a94pNmMh4buul9rHLpJ1MV1Mw6jONw7m7pdE8OJSW6GsctU3pFkkV+dU7md7CBuItr /8XapDO7z6s1qmsOABH4gtcrMrrLwcmnebzrzunh9GFrLRAYfcMWda2VJBMh0oMLMEpW EikqWd9tlPn1wdDO3FsTQDRdapsMkNEAGhZBQP8/vrt14AYE57C3NC+M3cviA53C42wH VGoH1hUYCXBi8l4g5zmjaAl4hbIdFtx0JrDBic4gFrxKDU+PTrIqbBeG/RgSEyJquci2 EM+l3I4KAu1bLHJkL7GcgBHp4dm7p9nqiTA2DknCvvpgoO1UuN7lwmSBXmJ8pbZYzaOp Kg+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771912010; x=1772516810; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qNr8d1nrqZZDfnro4iFgBQlAdVfxjJDLWxz4pVReYn8=; b=v6OadlwZQ0q3QZ7xGdRnCym+RYKdS2XSO9Rd3X6zyn9zdqTS+e1aP7XEjshKsph88C t9lYshAvnkCyloi+lIyk8hJIUVB36aTKEUtKJeRGY/gp1sIaBA7kLSUdErmO5BCr8BAo E76EfvzbIuscfzpcDZzBACvWXVcH+7Dqtz+uaKjIVb112sqNTZnGwRdKv59LSxI6shuw /2hv2SiTb2M/Hx4uVRv285eATlexiPMSajIqtiREovymCQwCnFcG9PaUnsvaDQUaWbsu v4bcEJnuU3W2Aadf2p7nbS0Byo04Nt/Nn8v2JZpb+5ysnmCRXIBBEO6yLKDPDLXphTjf 3dZQ== X-Forwarded-Encrypted: i=1; AJvYcCUPp8nKdExGJ2cB/4oBiXywO1/E/qbwlWe0By9aIOe5v3bvvVZVfsjJLg13T5RQmltatZ7/UC8Bhja+Z60=@vger.kernel.org X-Gm-Message-State: AOJu0Ywmo6aexE4YaIzhDjtM4ZZQIEneyQrYbKpnz/a5HtXEQaNcUSXd 3RxuB3xxewV2rUE/DjGjta7aM4poPc3DkwVrYCxszIzs2JzzDSJ6tBbeDMDT2A== X-Gm-Gg: AZuq6aK7i/CRSAIbgl/BqXxpJxmwWesrkcp/B7rp0J5+3W2vJod4esVjI46NFcYvHF3 VuHb2WHcr2D0KzQw6TTjHyjhJQleAGsFp27Z8xJu4NdWLa1Wh/l99ngU+ovbVB/SJifB2AtBYc6 jXS9WybssBm7KZqvzqL5uHyF9uDiiUauGHyYlCrJH2ZN+cZscMEXHjqeKbqMWCvjiXVegP6boQ1 CfSrknRgxcFlHWfSYs1z3GLlvEUdpktsmPRaL0CJJ/Er7GwYkpjPhy1QnBfAYCiutxwCiOXSUjG 6Uvb4mXvpOxe662l4cWaLwrqXGSCO0hnu1yr04r1cTx28++4JrEZn6DuDwxEQGweOeRhgicOtWL DEgGf6gbrfoL6VsjalxIx11pKzE6XucrlDNYN3HL1HO+tP/IHkzHKkjsqN6lT96UJu6TAurqOW2 wBU31WAvtD+iZG3IhwcZxWjPgCLS0e3Vgv X-Received: by 2002:a05:6402:274c:b0:65c:972:7073 with SMTP id 4fb4d7f45d1cf-65ea4f16218mr6808405a12.28.1771905169453; Mon, 23 Feb 2026 19:52:49 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65eab9a077asm3269354a12.4.2026.02.23.19.52.47 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Feb 2026 19:52:48 -0800 (PST) Date: Tue, 24 Feb 2026 03:52:47 +0000 From: Wei Yang To: Vernon Yang Cc: akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang Subject: Re: [PATCH mm-new v8 2/4] mm: khugepaged: refine scan progress number Message-ID: <20260224035247.r6mxsfcpiev4wnce@master> Reply-To: Wei Yang References: <20260221093918.1456187-1-vernon2gm@gmail.com> <20260221093918.1456187-3-vernon2gm@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260221093918.1456187-3-vernon2gm@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) On Sat, Feb 21, 2026 at 05:39:16PM +0800, Vernon Yang wrote: >From: Vernon Yang > >Currently, each scan always increases "progress" by HPAGE_PMD_NR, >even if only scanning a single PTE/PMD entry. > >- When only scanning a sigle PTE entry, let me provide a detailed > example: > >static int hpage_collapse_scan_pmd() >{ > for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR; > _pte++, addr += PAGE_SIZE) { > pte_t pteval = ptep_get(_pte); > ... > if (pte_uffd_wp(pteval)) { <-- first scan hit > result = SCAN_PTE_UFFD_WP; > goto out_unmap; > } > } >} > >During the first scan, if pte_uffd_wp(pteval) is true, the loop exits >directly. In practice, only one PTE is scanned before termination. >Here, "progress += 1" reflects the actual number of PTEs scanned, but >previously "progress += HPAGE_PMD_NR" always. > >- When the memory has been collapsed to PMD, let me provide a detailed > example: > >The following data is traced by bpftrace on a desktop system. After >the system has been left idle for 10 minutes upon booting, a lot of >SCAN_PMD_MAPPED or SCAN_NO_PTE_TABLE are observed during a full scan >by khugepaged. > >>>From trace_mm_khugepaged_scan_pmd and trace_mm_khugepaged_scan_file, the >following statuses were observed, with frequency mentioned next to them: > >SCAN_SUCCEED : 1 >SCAN_EXCEED_SHARED_PTE: 2 >SCAN_PMD_MAPPED : 142 >SCAN_NO_PTE_TABLE : 178 >total progress size : 674 MB >Total time : 419 seconds, include khugepaged_scan_sleep_millisecs > >The khugepaged_scan list save all task that support collapse into hugepage, >as long as the task is not destroyed, khugepaged will not remove it from >the khugepaged_scan list. This exist a phenomenon where task has already >collapsed all memory regions into hugepage, but khugepaged continues to >scan it, which wastes CPU time and invalid, and due to >khugepaged_scan_sleep_millisecs (default 10s) causes a long wait for >scanning a large number of invalid task, so scanning really valid task >is later. > >After applying this patch, when the memory is either SCAN_PMD_MAPPED or >SCAN_NO_PTE_TABLE, just skip it, as follow: > >SCAN_EXCEED_SHARED_PTE: 2 >SCAN_PMD_MAPPED : 147 >SCAN_NO_PTE_TABLE : 173 >total progress size : 45 MB >Total time : 20 seconds > >SCAN_PTE_MAPPED_HUGEPAGE is the same, for detailed data, refer to >https://lore.kernel.org/linux-mm/4qdu7owpmxfh3ugsue775fxarw5g2gcggbxdf5psj75nnu7z2u@cv2uu2yocaxq > >Signed-off-by: Vernon Yang >Reviewed-by: Dev Jain >--- > mm/khugepaged.c | 42 ++++++++++++++++++++++++++++++++---------- > 1 file changed, 32 insertions(+), 10 deletions(-) > >diff --git a/mm/khugepaged.c b/mm/khugepaged.c >index e2f6b68a0011..61e25cf5424b 100644 >--- a/mm/khugepaged.c >+++ b/mm/khugepaged.c >@@ -68,7 +68,10 @@ enum scan_result { > static struct task_struct *khugepaged_thread __read_mostly; > static DEFINE_MUTEX(khugepaged_mutex); > >-/* default scan 8*HPAGE_PMD_NR ptes (or vmas) every 10 second */ >+/* >+ * default scan 8*HPAGE_PMD_NR ptes, pmd_mapped, no_pte_table or vmas >+ * every 10 second. >+ */ > static unsigned int khugepaged_pages_to_scan __read_mostly; > static unsigned int khugepaged_pages_collapsed; > static unsigned int khugepaged_full_scans; >@@ -1231,7 +1234,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a > } > > static enum scan_result hpage_collapse_scan_pmd(struct mm_struct *mm, >- struct vm_area_struct *vma, unsigned long start_addr, bool *mmap_locked, >+ struct vm_area_struct *vma, unsigned long start_addr, >+ bool *mmap_locked, unsigned int *cur_progress, > struct collapse_control *cc) > { > pmd_t *pmd; >@@ -1247,19 +1251,27 @@ static enum scan_result hpage_collapse_scan_pmd(struct mm_struct *mm, > VM_BUG_ON(start_addr & ~HPAGE_PMD_MASK); > > result = find_pmd_or_thp_or_none(mm, start_addr, &pmd); >- if (result != SCAN_SUCCEED) >+ if (result != SCAN_SUCCEED) { >+ if (cur_progress) >+ *cur_progress = 1; > goto out; >+ } How about put cur_progress in struct collapse_control? Then we don't need to check cur_progress every time before modification. -- Wei Yang Help you, Help me