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 AEB533F23AA for ; Tue, 17 Mar 2026 16:52:16 +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=1773766336; cv=none; b=AJnHgOnWhHQgCi/Bcf4EXx2RBlx2eu94Tr89UQCSKe3vHbObNMfUV27yVwLcs+FBfmrI6S3ZO2RuIMuXxV4xvVxWlR6m7UXaxB4aafgIBR0qxAaK/Qc1R8wpAMSOs9XzD6EhDeGGNnUr4bBOonNM/jTsJBa6h14CzJgf9EDWtpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773766336; c=relaxed/simple; bh=/hoB1sO0J8/RDD1AeuSJTXY291QSQFnBtallbctCtdY=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=cIXTI3zsbVRbRKwisv5MpOQ9ca5Tktn7+NdvIdFLp8TI+vqNWphmfHBRKnBFSP+D4DZKz5nu/X9j9EKdSNDdOReMwLUWv+7k9EvjQJmhDdIxs1/94z4WI5EYQhRfWWO+cVTfTYqSYNvzVYpibvwnkU1ykXdyY53wtDYYGXPgLUc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=XpIlqsRY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="XpIlqsRY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4487C4CEF7; Tue, 17 Mar 2026 16:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1773766336; bh=/hoB1sO0J8/RDD1AeuSJTXY291QSQFnBtallbctCtdY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XpIlqsRYEe2SxDQVq5auvQeATk74ih0mn9WgbAexAhU+Rq1ZO0SnKKK19K9S6V/u7 S2sQ8XWpFAPiML62L0t3w2HlOry6WIGT6DIZu+w4lSfcphMLG9VrhzLdXLrSzPpCm4 DnhY3Sb72RWi1L6MWWt0ACeOCV6HhdpaiBAiakOg= Date: Tue, 17 Mar 2026 09:52:15 -0700 From: Andrew Morton To: Breno Leitao Cc: David Hildenbrand , Lorenzo Stoakes , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, usamaarif642@gmail.com, kas@kernel.org, kernel-team@meta.com, "Lorenzo Stoakes (Oracle)" , Wei Yang Subject: Re: [PATCH v7 0/4] mm: thp: reduce unnecessary start_stop_khugepaged() calls Message-Id: <20260317095215.26a696018c6d3d1acb8e35f2@linux-foundation.org> In-Reply-To: <20260317-thp_logs-v7-0-31eb98fa5a8b@debian.org> References: <20260317-thp_logs-v7-0-31eb98fa5a8b@debian.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Tue, 17 Mar 2026 08:33:55 -0700 Breno Leitao wrote: > Writing to /sys/kernel/mm/transparent_hugepage/enabled causes > start_stop_khugepaged() called independent of any change. > start_stop_khugepaged() SPAMs the printk ring buffer overflow with the > exact same message, even when nothing changes. > > For instance, if you have a custom vm.min_free_kbytes, just touching > /sys/kernel/mm/transparent_hugepage/enabled causes a printk message. > Example: > > # sysctl -w vm.min_free_kbytes=112382 > # for i in $(seq 100); do echo never > /sys/kernel/mm/transparent_hugepage/enabled ; done > > and you have 100 WARN messages like the following, which is pretty dull: > > khugepaged: min_free_kbytes is not updated to 112381 because user defined value 112382 is preferred > > A similar message shows up when setting thp to "always": > > # for i in $(seq 100); do > # echo 1024 > /proc/sys/vm/min_free_kbytes > # echo always > /sys/kernel/mm/transparent_hugepage/enabled > # done > > And then, we have 100 messages like: > > khugepaged: raising min_free_kbytes from 1024 to 67584 to help transparent hugepage allocations > > This is more common when you have a configuration management system that > writes the THP configuration without an extra read, assuming that > nothing will happen if there is no change in the configuration, but it > prints these annoying messages. > > For instance, at Meta's fleet, ~10K servers were producing 3.5M of > these messages per day. > > Fix this by making the sysfs _store helpers easier to digest and > ratelimiting the message. > > This version is heavily based on Lorenzo's suggestion on V1. > > --- > Changes in v7: > - Keep the atomic test_and_set_bit() in set_global_enabled_mode (Sohil) > - Link to v6: https://patch.msgid.link/20260311-thp_logs-v6-0-421e30d881e0@debian.org Thanks, I updated mm.git's mm-unstable branch. Below is how v7 altered mm.git: --- a/mm/huge_memory.c~b +++ a/mm/huge_memory.c @@ -353,11 +353,11 @@ static bool set_global_enabled_mode(enum for (m = 0; m < ARRAY_SIZE(thp_flags); m++) { if (m == mode) - changed |= !__test_and_set_bit(thp_flags[m], - &transparent_hugepage_flags); + changed |= !test_and_set_bit(thp_flags[m], + &transparent_hugepage_flags); else - changed |= __test_and_clear_bit(thp_flags[m], - &transparent_hugepage_flags); + changed |= test_and_clear_bit(thp_flags[m], + &transparent_hugepage_flags); } return changed; _