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 98EDC3E6DF7 for ; Wed, 13 May 2026 08:57:21 +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=1778662643; cv=none; b=UOo6LoAd7HWrR3V/4cPhawDm04gG1boLdZaWOjKq2fZStbaSZVj2KYzpC0Z/0A2pbIqfwnxL/JAMefFn+aAvyUK91NQomBpPaIEdaotJP9+n6sdMrrDq+GoQHmngRcHSpQBa1OQ+dXmieYlVj+5J9/is52AbQezcogYbbZPb7JM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778662643; c=relaxed/simple; bh=S7GwIAiUCQltnlUa2mOf33ISO6ume+fnsS9+fZ/PLDQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VFMYFo8fP0BTOwbGXM5tVWQFHGA3IZlasfO1rvGvVpK6qPkiy73Ydxm3Dl7kDp5uXhkp9qS2GaRfcTPDw+zERMWAUIvWDF8g/f18LvaeXQnwAlomoM5lCSU59jnhqWGj4WQjii0ek+sKnw3v6Htkh+RR28k21hWcHny7vCWRkJo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=ZfbIcZR3; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="ZfbIcZR3" 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=S7GwIAiUCQltnlUa2mOf33ISO6ume+fnsS9+fZ/PLDQ=; b=ZfbIcZR3ZzNjzKikmMIuW0z1Xt IYCp1T2miKkSNFo/1S7GA14NHOaqHtkEWeOxtPxsUU/0jjJxTzr7EZFoKoGkM3m3XzCBQBXK4eRxP 9qt2SeF86cDfdBxlFt2rHBQBdo4vZi7tjpWZ7BHujku1uzLWYbVOzbYMxsQoL1v3aohKAEB+K1qhX AcRLfqHON5ykgFe7Do4uw1M/+sI30aFl7kcQhpQVyBoGJ4FiUmR0eURkAnkV63usLma+wX1rXVSiz hfRmudlDgSH1x5zjKrhwuPtx6G3kB8bS7O1QkwCOoW6mohwKQbEmCUu8agrQJU8oW3MJWIJfTpS3h BWQTpHTg==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wN5Oq-0032xN-0C; Wed, 13 May 2026 08:57:04 +0000 Date: Wed, 13 May 2026 01:56:59 -0700 From: Breno Leitao To: ranxiaokai627@163.com Cc: baolin.wang@linux.alibaba.com, akpm@linux-foundation.org, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, ran.xiaokai@zte.com.cn Subject: Re: [PATCH 1/2] mm: huge_memory: refactor thpsize_shmem_enabled_store() with sysfs_match_string() Message-ID: References: <7b8cb44c-a098-4430-a8ef-142fa7a19087@linux.alibaba.com> <20260513082558.50743-1-ranxiaokai627@163.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: <20260513082558.50743-1-ranxiaokai627@163.com> X-Debian-User: leitao On Wed, May 13, 2026 at 08:25:58AM +0000, ranxiaokai627@163.com wrote: > >On 5/12/26 8:05 PM, ranxiaokai627@163.com wrote: > >> From: Ran Xiaokai > >> > >> Inspired by commit 82d9ff648c6c ("mm: huge_memory: refactor > >> anon_enabled_store() with set_anon_enabled_mode()"), refactor > >> thpsize_shmem_enabled_store() using sysfs_match_string(). > >> This eliminates the duplicated spin_lock/unlock(), set/clear_bit(), > >> calls across all branches, reducing code duplication. > >> > >> Tested with selftests ./run_kselftest.sh -t mm:ksft_thp.sh, > >> all test cases passed. > >> > >> Signed-off-by: Ran Xiaokai > >> --- > > > >Thanks for doing this. Ack. I appreciate you taking the initiative to convert the remaining instances. > >Moreover, I think we can follow commit 82d9ff648c6c's approach: if > >nothing changed, we don't need to call start_stop_khugepaged(). > > Thanks for the review. > Yes, indeed, We can further optimize this by following the approach > in commit 82d9ff648c6c. Agreed, that would be a good improvement. > It seems odd to still call set_recommended_min_free_kbytes() when the > mode hasn't changed. Maybe this is to handle the case where the user > modified /proc/sys/vm/min_free_kbytes in this timewindow? You're right that it appears unusual. The rationale is to avoid breaking userspace for applications that may be 'triggering' this behavior by rewriting the same value to sysfs. While this isn't an expected use case, we need to maintain backward compatibility. The discussion around this took place here, if you're interested in the context: https://lore.kernel.org/all/ec07d7f0-cad4-4d9b-8e40-d4ded8170340@lucifer.local/ Please CC me on the next revision. Thanks, --breno