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 B08F735E92E for ; Fri, 6 Mar 2026 11:22:42 +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=1772796162; cv=none; b=hosIf1j/LK8OT1nWsfeiMmcGqz4ZV9BbEzVGB32vksy8VZYpJPgDKflbLiSb41kF9odbX8wi/9b4laya31nN0+DBRSUxehy5vC/3vL+CCvsPcZEU+bO8EqVR34z+8AkMTRdTd9rG4tHhRbNOyFLb5mdFSULAQWSAvgd50KwVXro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772796162; c=relaxed/simple; bh=2SvhT1C5WjYcV9xC7T8OBnpoJjplcky3WZNU2kHXa10=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DIO4q6jG5IQAbLCkon5RUScfgVJeWiFBoHiQaM/b8QWmFyDuAx/yX2xWHj0kXC4dHmtqYfvT4dd/KbGA21OpllPeokAwnt7Cz4yAVPKGx3KJFMSJH++xtgjTOGkYwZJJKTaOMWtO/gM+OObEcTDIAi5hJHeW8Jc7gT24pJlOALg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gyjoiYFu; 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="gyjoiYFu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC26FC4CEF7; Fri, 6 Mar 2026 11:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772796162; bh=2SvhT1C5WjYcV9xC7T8OBnpoJjplcky3WZNU2kHXa10=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gyjoiYFuU4oiuz2tYNq+r9zAk9iadm6YZHQHzpCX5QiBvcEpB6pIdFgJAxebfYj7x Oj4H921zSgUgxKLYNKeyvI+Zgjr9cJy0KErbixhrR314dNcs4LXpTtFPW4M+SSPaDT JoM92ylJ40Xm7OrGLf059kMfnjPqaQJrquvq55ikIR21YFjmaRmbssSruJavTL8Eu8 7faK5SHU0LbndcgZpQram2X4BlI5DhsAT51UAv2JpecON2vimG5dy3KDvMTNONIAln 34KYdD2MUqkPLy7XZle17Lrw8hxflv0rLgkOWYpfIgK0GhB4yEdqd08Kfj9HlGpnQ7 cAnlIiSg3Sh0w== Date: Fri, 6 Mar 2026 11:22:39 +0000 From: "Lorenzo Stoakes (Oracle)" To: Breno Leitao Cc: Baolin Wang , 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 Subject: Re: [PATCH v2 2/3] mm: huge_memory: refactor anon_enabled_store() with change_anon_orders() Message-ID: <789df8d5-7d03-4e3d-90b6-08f27af330b2@lucifer.local> References: <20260305-thp_logs-v2-0-96b3ad795894@debian.org> <20260305-thp_logs-v2-2-96b3ad795894@debian.org> <8b238664-4375-413c-a8cc-105d98430362@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Mar 06, 2026 at 02:30:22AM -0800, Breno Leitao wrote: > On Fri, Mar 06, 2026 at 02:07:50PM +0800, Baolin Wang wrote: > > > + mode = sysfs_match_string(enabled_mode_strings, buf); > > > + if (mode < 0) > > > + return -EINVAL; > > > - if (ret > 0) { > > > - int err; > > > + if (change_anon_orders(order, mode)) { > > > + int err = start_stop_khugepaged(); > > > > Thanks for the cleanup, and the code looks better. > > > > > - err = start_stop_khugepaged(); > > > if (err) > > > - ret = err; > > > + return err; > > > + } else { > > > + /* > > > + * Recalculate watermarks even when the mode didn't > > > + * change, as the previous code always called > > > + * start_stop_khugepaged() which does this internally. > > > + */ > > > + set_recommended_min_free_kbytes(); > > > > However, this won't fix your issue. You will still get lots of warning > > messages even if no hugepage options are changed. > > Correct — this was part of the earlier discussion, where the suggestion > was to retain the set_recommended_min_free_kbytes() call even when it > is a no-op. > > As for the warnings, I see a few possible approaches: > > * Remove them entirely — are they providing any real value? > * Apply rate limiting to reduce the noise I think rate limiting is the sensible approach. > * Something else? > > Thanks for bringing this up, > --breno > Cheers, Lorenzo