From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 C272E2D47FF for ; Fri, 6 Mar 2026 10:27:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772792834; cv=none; b=KYOrYPyCKPEya8bE9c/sxXIxXB7pgP/8NPcfB2b15FmXLrw5RHEiFuoC/2dGkBhVCWvaTin4MXvpJAVn/MV3OFChKwNiXZeK6urwl3HQpUndOX+lpyc3y2tHpvQzTiKzrbBQCM1Bk/zKEyyXxnv0qpTt2jl38NOO9aHFsha8vSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772792834; c=relaxed/simple; bh=VFRgcpRPtAIVkVATJLKF77b5jw5HImt7ATaRyk+lTPM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B8x+AiZHptncwhF7wggXJqza2+RcMcT0cNKohPMAsy/LZmt9htZ+vjfGbN9L5fLFAKYy5xMNnl/O56z+XlBoK+dxhb/oAfK/t5pYlmuMHrkG1BCjv4F4OWNHiWN2IAXXiVcRf79CE2bQr9bROsL8uQb8sQ3AlcLy+xXPxrH+jHM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=jjomhTxU; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="jjomhTxU" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=iydKHV9b8DDclbM7C79GoisWwPtgGu4Ax9AsDL9olKo=; b=jjomhTxUqjuzCOHM3x5X82GUr1 lll7DgHYwCewM9SP3LEGlCITTMkQSte1C5KucPOC6KTMSMAT5sXEBPZVuswWiGPMHCt8E7WhTPUqK jOpMTVOpjTufGLAaRVSM7RXZTgFl4cn8tg3YU848PpbJBGw5F0e2a9WZTbaHoYJi8Wqqb8RwJOI92 dKKhNz7v61rW0ECQTq1BMTLdZnaIKBpC062FKm+oQunslZJ1tvtcvhXkhutuezDCyQPSOwCSKByJn zNzlam+a5ESFeVaz7Nnldu2uWYLUb/kt46i3eae9hvukbWW20FqVGIHmaKxD0LTbbQ7HbupB08sZQ CKl7Fz3A==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1vySOL-00HR16-LC; Fri, 06 Mar 2026 10:26:45 +0000 Date: Fri, 6 Mar 2026 02:26:38 -0800 From: Breno Leitao To: Baolin Wang Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Zi Yan , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, usamaarif642@gmail.com, kas@kernel.org, kernel-team@meta.com, "Lorenzo Stoakes (Oracle)" Subject: Re: [PATCH v2 0/3] mm: thp: reduce unnecessary start_stop_khugepaged() calls Message-ID: References: <20260305-thp_logs-v2-0-96b3ad795894@debian.org> <3d3ee8ee-2aa1-4351-9965-c9ed5b858c96@linux.alibaba.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: <3d3ee8ee-2aa1-4351-9965-c9ed5b858c96@linux.alibaba.com> X-Debian-User: leitao On Fri, Mar 06, 2026 at 02:14:31PM +0800, Baolin Wang wrote: > > > On 3/5/26 10:04 PM, 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 a no-op if there is no state > > change. > > > > This version is heavily based on Lorezo's suggestion on V1. > > Thanks for doing this. And you should also consider the shmem parts: > shmem_enabled_store() and thpsize_shmem_enabled_store(), both of which will > also call start_stop_khugepaged(). > > That means you can also generate lots of messages with the following script. > > # for i in $(seq 100); do > # echo 1024 > /proc/sys/vm/min_free_kbytes > # echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled > # done Thanks for the input, I will include it in the fixes also. --breno