From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (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 863AE372678 for ; Mon, 18 May 2026 13:36:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779111383; cv=none; b=aJLeBvP/1/BRCQmHh1TmpuKdAd+N7ymwptYVMVs75Pd8BT4ouBXtyd3LOfwBs9imtSYtK7FTeeCco1X6q+ya2OsicE9wXbvM22ecq4rROOTA3ZoOrpmxWG7KgMmaD/P1hnyQl+pATwwZsZHZwFkBmAEEqly5yvDyTiroJjEoXeM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779111383; c=relaxed/simple; bh=IGf6wm8G3bCjVfjjm0dZ0RkR07fESApKD3tiLN1XB+8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TG2SphOym51Kc0A773xjUXVFWmIbATSx/0cT3/43Nm4xJGsBqkOhE/Erxwbz3AxwK8SDbGMkU9O+jiXTK/sCXPBPGyE/axgIoLTVf6yx+wl6N5K596kvFbWzALFL9nFdOAiha6v9kKSXco+IgrXOvA1pgGZMCTsqfafWE0LRRJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=oJWzCMpw; arc=none smtp.client-ip=91.218.175.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="oJWzCMpw" Date: Mon, 18 May 2026 15:36:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1779111379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wLYTNzx6qKYmwmydwCXN1JQ85CVWzi46LWy8nleiQKw=; b=oJWzCMpwM8hegQDfXOi2jqn3Fw2tZ1wwSamfRx4AcSsQzoLP6DBOnQLZXRTKicCOen+XjB SsoOwEN7JABpxSPF9OekH/DYaxaij6edPY5XZmHZ1vQYQSXOiTf9k8VADxdhwnO51/KU72 IJ1xx2v2j4Jo9UuxXWnfYKpcjpwrBg4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Thorsten Blum To: Lorenzo Stoakes Cc: Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Yury Norov , Rasmus Villemoes , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Message-ID: References: <20260517123428.1181981-4-thorsten.blum@linux.dev> 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-Migadu-Flow: FLOW_OUT On Mon, May 18, 2026 at 01:33:54PM +0100, Lorenzo Stoakes wrote: > On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote: > > [...] > > Patch 3/3 is one of many examples that pulls in all of mm.h just for > > offset_in_page(). lib/string.c from the same thread [1] is another > > example that would need to include mm.h just for offset_in_page(). > > And that's a problem why? Compile time? Somehow binary bloat? Conflicts? > Confusion? This is more about separation of concerns than about compile time, which can still matter here, since mm.h is large, pulls in many other headers, and any changes to those can cause unrelated files to be recompiled. I don't mind including mm.h where the code already depends on MM interfaces, but offset_in_page() itself is a small page-arithmetic helper. Having it buried 3000+ lines into mm.h also makes it less discoverable, which may be one reason it's not used more often. > > Many other files (hundreds) don't use offset_in_page(), but open-code it > > in many different ways instead: > > > > (unsigned long)p & ~PAGE_MASK > > (unsigned long)p & (PAGE_SIZE - 1) > > (long)p & (PAGE_SIZE - 1) > > ... > > > > I can't tell whether they didn't know about offset_in_page(), or > > deliberately chose not to include mm.h. > > OK but this series doesn't address any of that? It just adds a new header, a > questionable macro and uses it in one place? So those justifications are rather > moot here. My intent was to make the helper available from a smaller header first, and to use patch 3/3 as a concrete example where including all of mm.h is unnecessary. Other call sites can then be converted incrementally over time, rather than sending a tree-wide conversion in the same series. Thanks, Thorsten