From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 CD2C1345734 for ; Fri, 6 Mar 2026 06:14:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772777685; cv=none; b=OZNsjIeAQ+WppvbZRYdkeaGDKSV02mugucpKZUtrPYEZqsXJAYQpWeW9EuksFRY+QGnwk7uqOH3gQ+u16bPe5jIs3mphDneKtRShKft8QTydywRLVvTtKhgWpDNrBdajBqsUpVcVDHJp/vhLRPjTvUKuBGBDAGIZz5JGbDtpOA0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772777685; c=relaxed/simple; bh=8MNopfA1W3W4nTJx/YSc9xYcsg0vdML5YOeVks4wSAY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jYXTa/oKPelirvvr9AKzZVFRIbA0qvBZzRj6SaZF6qZqs1wpmzKK9oJ9NJvhSUvi0zKzXd0f/hSjf6jRShP+bbNE+ctZlcSvxDDot9Qozr3/5mf2hsflQM7PZX69OMgOjmMK6cs4WJgWJ7+foNezjPm5tRB4oyuA2NNhneAaL+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=fj/0F+PJ; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="fj/0F+PJ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1772777674; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=zmRPAF62Mchrk/WjhbPTvXdOO9DYmUP5hbIL4elCOy8=; b=fj/0F+PJu/DjJV98GuLu0GmdURABbd5aps6cb6E0x1C4p7HuiROKdGMW9sP4jBifq5Khtc9kbYovojL7SkGy9V9HPRKpV4i1ARfwV+p8Ike+1K8TW/bLzCPJlraGDelI5BNYv0GE775lLUlTLgTWPxvrU5NCl6O5o5vBW+ykITQ= Received: from 30.74.144.109(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X-MLeMQ_1772777671 cluster:ay36) by smtp.aliyun-inc.com; Fri, 06 Mar 2026 14:14:32 +0800 Message-ID: <3d3ee8ee-2aa1-4351-9965-c9ed5b858c96@linux.alibaba.com> Date: Fri, 6 Mar 2026 14:14:31 +0800 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 0/3] mm: thp: reduce unnecessary start_stop_khugepaged() calls To: Breno Leitao , 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 Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, usamaarif642@gmail.com, kas@kernel.org, kernel-team@meta.com, "Lorenzo Stoakes (Oracle)" References: <20260305-thp_logs-v2-0-96b3ad795894@debian.org> From: Baolin Wang In-Reply-To: <20260305-thp_logs-v2-0-96b3ad795894@debian.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > --- > Changes in v2: > - V2 is heavily based on Lorenzo and Kiryl feedback on v1. > - Link to v1: https://patch.msgid.link/20260304-thp_logs-v1-0-59038218a253@debian.org > > --- > Breno Leitao (3): > mm: khugepaged: export set_recommended_min_free_kbytes() > mm: huge_memory: refactor anon_enabled_store() with change_anon_orders() > mm: huge_memory: refactor enabled_store() with change_enabled() > > include/linux/khugepaged.h | 1 + > mm/huge_memory.c | 135 +++++++++++++++++++++++++++++---------------- > mm/khugepaged.c | 2 +- > 3 files changed, 90 insertions(+), 48 deletions(-) > --- > base-commit: 9dd5012f78d699f7a6051583dc53adeb401e28f0 > change-id: 20260303-thp_logs-059d6b80f6d6 > > Best regards, > -- > Breno Leitao