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 D6636269811 for ; Thu, 1 Jan 2026 02:04:57 +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=1767233104; cv=none; b=pLGP4QhAy7vHIB3Mq0r8Ey073qK3GanR/0is/FNYJ+UphRO7uV4EjvpfLlYzvWnWNrivMQRQ3Nm/sWdSL2y7cLP+Y8EeRjaqUsCxASmY//c0mYOa5xQJnFGg22Gh1hLYj5wdsXVDQW7uQd9QXgI4PMR4kEPxNuhYoa8lljMVZoU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767233104; c=relaxed/simple; bh=Oexr91tGBJoujLSg9ZM08aFr3Ymv3v77XTNar+4T59Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MxLSyS9wWwrcAO+HagzgK8e++RjJs0iQhw1kR6VnRdBwBbb80y0F3jv6K8xaBCR2i/M/ZPmGeW47FUlI5RT8+xc8INSojAUqKsJQEQELsezmwhhWN8lf5rgck+WZIgPdR1POOaWmbCzD0RD2LoKyMi9qPQMKMCIDfMexSE614XY= 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=UMRxxpKE; 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="UMRxxpKE" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-b72b495aa81so1852453666b.2 for ; Wed, 31 Dec 2025 18:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767233096; x=1767837896; 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=t4h33WmPmh9knOAQ2OtmSS5LD6H+sen3dTiFufGLTIE=; b=UMRxxpKEgrGc+4ggNm3FA0xq1O3tNXPrE6mvngNncmj2Os+9gsIOY//Mwv/WIG3EXC ZxMxbxhHwlyR9/I+mml0jTBtscbGefNb6JnjnKRNab9iTec7XBAggyfFSmJP5CzToxYP qUyNRSPgHUZSy5TwqOBX72+RNX/vk5iPlrfSQHaw5wv/BPpcbiNWSznYZQZ4BByarWt3 Wu/NlgN5daMkw6H4ls0oNZR40vpMo+IfRPkhdQAL6cdAUjqom8ff1KAny4mOqcFv0Xnu BJTY0453K+am99RkNCYQ1lv82ih+7RY2YBWwwZsNVYJbIGxcdUsXYUQzDg4bf7ZNpPzN Wumw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767233096; x=1767837896; 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=t4h33WmPmh9knOAQ2OtmSS5LD6H+sen3dTiFufGLTIE=; b=WJU3EFb3FJ4HyzTtIG8mITzPsCHllKq7XRWHi1KGPxSpyrmiCdAJvgF018teu+0NFu tCKQdQM/rkWBiABpAqM4E8AKFbzkKsUFwqg/BwMJz6Sx11Avg1JX4D9fhu5NXvX4JkuA apRIGjd8qfnlLIi2UtmYcZTqrPxfDBJKZE6BC6hb+/S0UAV0zGu3MWqwrVmWJYgQ7PV6 SoKFy/sYyf611p/Iwr2gJymdMDl/iJfmA9h/+pG8k91VX0zWnwfk8QG3a/04mim8+0Q3 Kcj5IhAPQmgS2rhq4fxRNjiPMGYY/699wQNZbwBln0rXp7cXXoElbruMWJ/nEUVKpVAU 8ziA== X-Forwarded-Encrypted: i=1; AJvYcCVIZxwR9YDV122+DOi40cjJdmy84MXfzeU5z94DrGkUPYLL0vEidwocUpP47hzJQWX/BGP9r27VSraK7M4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8JWkV1UmQxPBulzHxXM1lV3Rfo1yhLG/Zmzwj9TftZfqoT0RS y7Valpe43EU+zSw4gjDMSjN/OEWePXHUyTB4OIhcvYRtWdh41jflzTY1 X-Gm-Gg: AY/fxX4rr8X3CoDwG4vXvciE0a2ro3n7aRdsixDSaFBIUwvecpULgTeQnIUtSF3MHfs JtDogTDZZBRPKtyb9mUl++jTGBrZpGye571DnKPRQkiQbLrlZ3s7OXOE+Un6w5jZJfQAu+I/7m4 I+J3mE65lCska9YmMyJhi6FiC6l3N5j2yHGuacvPqzEdjxs5L75NxInhpSg6sI27DbKgeEkYxTS GjGZrTvrqR0ySVhrJOOHsSikLgrCjeOTKmGxvLOq28nAerj3FV7m9uN9st5kXZ0kBlaTKISUhQp YyaK8kPupZvZ+8BK1NEys6kLhVMg8KA3TjvEEnRDVeYlhD5WCN6n1sTqfS3cmXTE0O6pyWVoGag 2P9rMnzCo37l6Inn8bhHQmxjmoGP1jjLUA7+EyAGNrDsvPEY7oJE5o2BiRQXzX9odLXX7/UCzBB maawuF2uaBBQ== X-Google-Smtp-Source: AGHT+IFCnRN5BM6kVAHLy0RVPYJFMCs5SToyOj8yBYpIC2I9xHPhI6HdJIINOAMKk7wNRoMxzNkAfw== X-Received: by 2002:a17:907:960c:b0:b80:b7f:aa32 with SMTP id a640c23a62f3a-b80371da8f5mr4059310866b.41.1767233095827; Wed, 31 Dec 2025 18:04:55 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b83926533b7sm738659766b.20.2025.12.31.18.04.55 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 Dec 2025 18:04:55 -0800 (PST) Date: Thu, 1 Jan 2026 02:04:54 +0000 From: Wei Yang To: "David Hildenbrand (Red Hat)" Cc: Wei Yang , Vernon Yang , akpm@linux-foundation.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 v2 4/4] mm: khugepaged: set to next mm direct when mm has MMF_DISABLE_THP_COMPLETELY Message-ID: <20260101020454.unwjna3cdmcgpldp@master> Reply-To: Wei Yang References: <20251229055151.54887-1-yanglincheng@kylinos.cn> <20251229055151.54887-5-yanglincheng@kylinos.cn> <20251231025112.uzlgrs3dgbyzul2x@master> <9c3b81da-f0e8-4652-8900-05593e124c26@kernel.org> 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: <9c3b81da-f0e8-4652-8900-05593e124c26@kernel.org> User-Agent: NeoMutt/20170113 (1.7.2) On Wed, Dec 31, 2025 at 01:21:12PM +0100, David Hildenbrand (Red Hat) wrote: >On 12/31/25 03:51, Wei Yang wrote: >> On Tue, Dec 30, 2025 at 09:03:23PM +0100, David Hildenbrand (Red Hat) wrote: >> > 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 >> > >> >> This one looks better. >> >> But the sad thing is we can't remove this mm from scan list, since user may >> toggle this flag later. > >In theory we could readd it to the list once the flag gets toggled. > Currently we use khugepaged_enter_vma() to add one mm to scan list based on vma property, while toggling the flag MMF_DISABLE_THP_COMPLETELY is based on mm. If we want to readd it in prctl_set_thp_disable(), we need to change the semantic of khugepaged_enter_vma() or introduce another interface? >In fact, we could remove it from the list once we set the flag. But not sure >if that ends up any cleaner (dealing with races? not sure). > Removal is clear to me, but my concern is how we add it back. Looks a little unclear to me as described above. Another thing is how much "thp disabled" processes would we have in system? If not that much, check the flag and skip it in the scan looks enough. BTW, if we can skip all thp mapped process during scan looks more benefit? >-- >Cheers > >David -- Wei Yang Help you, Help me