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 99439347511 for ; Tue, 17 Mar 2026 11:49:17 +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=1773748158; cv=none; b=GG53HbY9clxXf9TufQNtQ5XgW84fH9hGK1li1h8PmKx656t17zZ1knx6HdYcjYJU2EwbFkrJwoNYPIKeFIf4Yej/Xn38fk0d/R5OyGH49TMzrpcgO/Zeta0kJYOwHW/22FGAIvOnptFF60IEvkF4bhiL4MPUcjCApFqgPwZi49s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773748158; c=relaxed/simple; bh=okqkmaSm7Oil+K+FOkzNnl0oNe1IKBvs8hrH3FIbkCA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u3YwljMJK14OVmRbeuqkealwMqcHsiQYCdreyKbQ5pU8xQkG912fB6pvuOXI/vHZ6sYlsvCdArkkrXVrd5TO5x5za3y+hQvUUoYiNgxKeR6Jioqi6efo0n90vAw2yyT/JGt9tloJrPIY0Aw1qeYZk1ZfwzWGotyb3CN+HDqXfPU= 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=v2kUwuWl; 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="v2kUwuWl" 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=0N0UaS69pBYbj3xcnEh+mIbQAk5ZDxTv3h+D8hQJdJc=; b=v2kUwuWlvUx/fG/zQ3I3JU232+ VeUy1r2VvJGOvEhPJBhNpa8ohzOurwCspdZlkCbyzRs7M/qlHsFihbQE04uGSuXBD8RDL4HLEQ/Zv qWmf+a5pD/xwZ5vCJAo+N/dkLgPL7uZqAF/tEIFOJwdfEhBNF7eDP0QSY/eljZRq/X+2SJ6Vh0qZv NZwlQ/xHFniOkGGpi+e1GbveyztdLs5eeINKsRgCxSpxHrgSR7UbSYR4neJO5T7PgxoZQ02Q64eCO c0w73u/2cU2KpIsPDYz3B0lfqb0FiasE0yLbmQhGDXBb61GtMNKtMJPmi/xDINjCz4wy4hkfkugR1 IAU4n1+g==; 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 1w2Suv-002rYf-Kb; Tue, 17 Mar 2026 11:48:56 +0000 Date: Tue, 17 Mar 2026 04:48:50 -0700 From: Breno Leitao To: "Lorenzo Stoakes (Oracle)" Cc: Sohil Mehta , 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 , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, usamaarif642@gmail.com, kas@kernel.org, kernel-team@meta.com, Wei Yang , "Accardi, Kristen C" Subject: Re: [PATCH v6 3/4] mm: huge_memory: refactor enabled_store() with change_enabled() Message-ID: References: <20260311-thp_logs-v6-0-421e30d881e0@debian.org> <20260311-thp_logs-v6-3-421e30d881e0@debian.org> <322f6f2f-840e-462f-96b0-b603b9c88582@intel.com> <1b7d1bdf-c002-4543-b858-09fd2b1b73f9@lucifer.local> <8f873cbb-93ef-40d9-99c8-ce9970aefb82@lucifer.local> 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: <8f873cbb-93ef-40d9-99c8-ce9970aefb82@lucifer.local> X-Debian-User: leitao On Tue, Mar 17, 2026 at 11:25:23AM +0000, Lorenzo Stoakes (Oracle) wrote: > On Tue, Mar 17, 2026 at 04:23:37AM -0700, Breno Leitao wrote: > > On Tue, Mar 17, 2026 at 09:37:39AM +0000, Lorenzo Stoakes (Oracle) wrote: > > > > > > Given the above I think we should switch back to the atomic accessors. > > > > > > We can address the broader issues with this horrible code in a separate > > > series. > > > > Ack. let me respin then. > > Thanks! > > > > > > > Overall, as you mentioned below, protecting transparent_hugepage_flags > > > > with a spinlock seems like a better, long-term solution to me as well. > > > > > > Yeah, let's look at doing a follow up that cleans this up in general and > > > address that then. > > > > Sure. I am planning to improve defrag_store() as the next work, and then > > come up with this additional spinlock for transparent_hugepage_flags. > > > > To be clear by the way by 'horrible code' I meant the existing logic with the > globals etc. not your change which is positive and welcome :) lol. Not once did it cross my mind that you might be referring to my changes. I have never written horrible code in my life. :-P