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 B2C432F5465 for ; Mon, 24 Nov 2025 09:14:26 +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=1763975666; cv=none; b=eOajaOyUYNGQxl8ugJnS8qLuQHdN/3+1/MqQFqvBoKe8idEK3gXR/UuX0kSXoItPMx6VBnEYK0kVlUWQce5T64T5ZD9CRx9NTS6bCfRMBYZpsMMnSzuhOmFdZ6/14vZSXmGJDUcl31q+5eMUOdorjek6kRRjepx61Z0CoYZ3dfc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763975666; c=relaxed/simple; bh=wSDWGmfP4BtDUejlk4PTmqLCNqx1SpwKuu1hUD0HOvU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uAlGaTV3awKT44GJ5XNaAjf4avicjdkg6T6fKStEH4NN48A7iFEEKgGFKC941fDScmtRTXLp3ZH0OdXbrWz3EizTzeB0d8cE/2t9BleTEO1ANI3XiUDe97foM5dp6CUzP3MpAqNdhbAds2NHB+IleIFPi4ZQFQxuZy09PZUqn4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SXTQAuyF; 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="SXTQAuyF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E224C4CEF1; Mon, 24 Nov 2025 09:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763975666; bh=wSDWGmfP4BtDUejlk4PTmqLCNqx1SpwKuu1hUD0HOvU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SXTQAuyFjbWMPPMUqKkaSRAcMBq36NrPA0oqdoKXV3fmzIS0S5/925qLXowvn1G1N LmvyD0AgBJth3FQh5Pf3Jkus83C7+orgUi0zUXtZZ7OdQAt0O2fHIxicEJqoFHGtWE cIwrdVCDkCF1fTZoEpJAlCP+/BjQy5rjmgpQWtcbH2mnbIN5T4V+zff4nPCKgaqOnw daYuNsI0OnLuHFh74PqJ8HDn44rn4hFk3SwpiHiGOgfdlKs8TcEhA2VjxLi6doHSMb U9xBiGp0l48mhchI5b7QDw78Xq+VH9rv38U5BuWxJUOfwXmrvLpusVcTaE4K+iBM7I qYy/y6vfTU9Wg== Message-ID: Date: Mon, 24 Nov 2025 10:14:20 +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] mm/khugepaged: Fix skipping of alloc sleep after second failure To: Zhiheng Tao , akpm@linux-foundation.org, lorenzo.stoakes@oracle.com Cc: ziy@nvidia.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, shy828301@gmail.com, zokeefe@google.com, peterx@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1763965157-58413-1-git-send-email-junchuan.tzh@antgroup.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <1763965157-58413-1-git-send-email-junchuan.tzh@antgroup.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/24/25 07:19, Zhiheng Tao wrote: > In khugepaged_do_scan(), two consecutive allocation failures cause > the logic to skip the dedicated 60s throttling sleep > (khugepaged_alloc_sleep_millisecs), forcing a fallback to the > shorter 10s scanning interval via the outer loop > > Since fragmentation is unlikely to resolve in 10s, this results in > wasted CPU cycles on immediate retries. Why shouldn't memory comapction be able to compact a single THP in 10s? Why should it resolve in 60s? > > Reorder the failure logic to ensure khugepaged_alloc_sleep() is > always called on each allocation failure. > > Fixes: c6a7f445a272 ("mm: khugepaged: don't carry huge page to the next loop for !CONFIG_NUMA") What are we fixing here? This sounds like a change that might be better on some systems, but worse on others? We really need more information on when/how an issue was hit, and how this patch here really moves the needle in any way. -- Cheers David