From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F9F735965 for ; Tue, 30 Dec 2025 20:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767125010; cv=none; b=GiFLVBUglrXMUYooGDDD5w7Uj1gmIvOo+mek83iia8lt94QsX3r9f1wioHd/cndt9ywn8onin1xKoy5RhqcaYF8P0rf0WhjZECFusjLujN11sjQsSVhv4ptWcxfq5a0r6XQNC6Kd6v7nuVRumBm9X2dN4Z1dW+UUo7tkln3h3d4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767125010; c=relaxed/simple; bh=YNrIbUP7Yffo+oKA8DDjbWGcIaKo1esvkxdt3/Xo/rQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jS5PlMStjn7ZVPSlyzDtrYHAeysqvCUe2+zG0Y7lQEtnZZbjiCpM7kPV0wzbLQy+uA6cq/J+1VzY7CnnpvNbuoI2KbAzyhtgo+dkJpduU/VDNbvMfeubToT8mrR9dbsAJRJGJBWFxNSo+KGb4pfeHXwEB3AHlbMAu+2zXqama5I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T5Yy14uU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T5Yy14uU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8953EC4CEFB; Tue, 30 Dec 2025 20:03:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767125010; bh=YNrIbUP7Yffo+oKA8DDjbWGcIaKo1esvkxdt3/Xo/rQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=T5Yy14uUiNSsjiuB+9o3RPsKtquQhXgDfEMhk+ej9eErBOlvcxx22btCUTR3XjYDS Hdqc2pfYqgRU/OGN8CprBtdjhzSVvyEv75PAX19+L00BiN4Z0+V0Fe/7I0DqlejP3G RKIm6MUDGRvsK260R7dZDnlDKi056bYlCuidXK55vWwsm0PegOlP3hiDJih4NeP+5D 6atO6yffLPRR1Dqj9lJljukEKNHAp4H1IKrpPi7l2ejVGO2DU115RaiEZlroMCz8Ug Iwmv7e+WHsAmiv6gCQBiUXcjs8h4jLt03n0vQStZnbWNstw6NytwToJZoTWpltSISD qAqVqMeyDvcJg== Message-ID: Date: Tue, 30 Dec 2025 21:03:23 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] mm: khugepaged: set to next mm direct when mm has MMF_DISABLE_THP_COMPLETELY To: Vernon Yang , akpm@linux-foundation.org, lorenzo.stoakes@oracle.com Cc: ziy@nvidia.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, richard.weiyang@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang References: <20251229055151.54887-1-yanglincheng@kylinos.cn> <20251229055151.54887-5-yanglincheng@kylinos.cn> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251229055151.54887-5-yanglincheng@kylinos.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/29/25 06:51, Vernon Yang wrote: > When an mm with the MMF_DISABLE_THP_COMPLETELY flag is detected during > scanning, directly set khugepaged_scan.mm_slot to the next mm_slot, > reduce redundant operation. > > Signed-off-by: Vernon Yang > --- > mm/khugepaged.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 2b3685b195f5..72be87ef384b 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -2439,6 +2439,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, > > cond_resched(); > if (unlikely(hpage_collapse_test_exit_or_disable(mm))) { > + vma = NULL; > progress++; > break; > } I don't understand why we need changes at all. The code is mm = slot->mm; /* * 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; progress++; if (unlikely(hpage_collapse_test_exit_or_disable(mm))) goto breakouterloop; ... So we'll go straight to breakouterloop with vma=NULL. Do you want to optimize for skipping the MM if the flag gets toggled while we are scanning that MM? Is that really something we should be worrying about? Also, why can't we simply do a diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 97d1b2824386f..af8481d4b0f4e 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -2516,7 +2516,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, * Release the current mm_slot if this mm is about to die, or * if we scanned all vmas of this mm. */ - if (hpage_collapse_test_exit(mm) || !vma) { + if (hpage_collapse_test_exit_or_disable(mm) || !vma) { /* * Make sure that if mm_users is reaching zero while * khugepaged runs here, khugepaged_exit will find -- Cheers David