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 4EC463537FD for ; Wed, 4 Mar 2026 11:54:08 +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=1772625249; cv=none; b=r7rKe9VTXI7Ap2khEZDOtHgMBJPaxwmzMNKgyG43u6+pi1fydfxB8JRJfHmBxzaw0kcNXKJZoxuR2icrPMNEZ0pU1RfRL5KJw4GQooV/kxW+MxMRO2vAAfIgNztNn42FTdQKHNgcjxpJNArwN0wH5Mwbd/8iCQaOgMaWgNZ1pGA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772625249; c=relaxed/simple; bh=fWnzB35AoCoUDPteJEqN3/BQLcI1kYNHClZQkOKUFXg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JlS1mKSAM29eoy6jr2mMGnPOk8nGaZqieP1oZklKGxDCWUtzbjuYMkvPE+7CGfND+DNiyOJnwBWVkTUjP4OlpqQs1Ji0rJzKF/lg3qYgQoJKETpQTZdlnJ+Ovl4xcO1Snus6VvInMLEmHVh/06+3OD0GkDM9jzFBBJViULJFe7E= 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=UtNhpP9/; 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="UtNhpP9/" 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=XyeYmlSBVFh6Us1p6vuGnch71Qpsd6kwji2Os7MZ4r4=; b=UtNhpP9/VGOjDVBNnLguF8mXmF dqlOnAI+BDMUKohF5M7VZoFeX66BZWvHAxqMBLbmSs0lF+64BWbDHcmZQBMITSReRiQJQD+7WkczJ ztlizWWhiUBakPXl4ItoHOO5PNZUlNj4H3LVQmuMt1Wg7Ee5Nj1Z9oBrXMmW5aD2C1F2FMFFMX6j5 5hx+ykQulwgmcp2+c29bPWOSPpxyaD9Ru3rSMq7Wkv+E6o2/P9Gad1yzfTa91Qbgj206uaYxTqjDX ACS9Cr2Eei+Q37aJlJSR44ZOcEyA60OKXLolZWMQwiHtxYqBVh4WT45fiBZVay/NI4yyPp2Xu4YuK dpbFo2Lw==; 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 1vxknO-00Fw0L-0O; Wed, 04 Mar 2026 11:53:42 +0000 Date: Wed, 4 Mar 2026 03:53:31 -0800 From: Breno Leitao To: Kiryl Shutsemau Cc: Andrew Morton , 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 , linux-mm@kvack.org, linux-kernel@vger.kernel.org, usamaarif642@gmail.com, kernel-team@meta.com Subject: Re: [PATCH 0/2] mm: thp: reduce unnecessary start_stop_khugepaged() calls Message-ID: References: <20260304-thp_logs-v1-0-59038218a253@debian.org> 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: X-Debian-User: leitao Hello Kiryl, On Wed, Mar 04, 2026 at 11:18:37AM +0000, Kiryl Shutsemau wrote: > On Wed, Mar 04, 2026 at 02:22:32AM -0800, Breno Leitao wrote: > > Breno Leitao (2): > > mm: thp: avoid calling start_stop_khugepaged() in anon_enabled_store() > > mm: thp: avoid calling start_stop_khugepaged() in enabled_store() > > I think the same can be achieved cleaner from within start_stop_khugepaged(). Thanks for the review. I considered this approach as well. From my limited experience, the preference is to return early in the _store() callbacks when the operation is a no-op, rather than pushing that logic deeper into nested code. Handling it at the _store() level results in more changes overall, but it is arguably more straightforward to reason about (!?). That said, I am no MM subsystem expert, and I am happy to go either way. --breno