From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (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 E215A30EF68 for ; Mon, 18 May 2026 11:54:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779105258; cv=none; b=M5tCDonaet8bYHVJLPAPrBzsz3qnWVJN62jkr6op+wcJiNlXJSfyuUIe0rGO4/fVzbDt/hHB7UAQ1zVvEgxr1e1F4C+sVj0pSnc4FBI4vhuf9cr9UlPJtdbFInw0PtSa+/piVw+LTsmS7Wr1Sjp1vzvAfqvVDgCwZ81FB5evilY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779105258; c=relaxed/simple; bh=8qYwxux0SPVYlgMp8q7xUG0kidTJ2oto8exBn7cJbd0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=YEZtTlO3LnLm1pgPjC5RNjwYShz7WDzNivZqySJvGM5CZ22+KhodPWMFRsb9kVv6dkh4Jm2hjlQ3IvLDF8zHNNDk18zF3coZ1qGwEYDdemYkwc+tSbplrFMWEItKnCteXOB/blge3MHXOoTfebgFauisRsz02A3Lv9+EWvJ5gfQ= 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=UQOPsdJR; arc=none smtp.client-ip=95.215.58.178 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="UQOPsdJR" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1779105252; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DNTRcHpJnCPUP+T3e8e3jYIUQU1ahRjyodrhYJFqx7g=; b=UQOPsdJRu83gqkQaOCeL2NIVWeK1LG+6BtYR+OlkKZb3XXXO4nvD3p//svgzuGgTF3FB/S HTkdMUFDtyQlSpwpVuj5iEmpZPRu32nqZP37jV8naBuN4Etpy1vwrjP7ucxUh5kR+zmOcX 8r8mxf9g5E2CxYLYiZ264UtdugDdPN8= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH 2/3] mm: add bytes_to_page_end() helper X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: William Kucharski In-Reply-To: Date: Mon, 18 May 2026 05:53:56 -0600 Cc: Andy Shevchenko , Yury Norov , Thorsten Blum , Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Yury Norov , Rasmus Villemoes , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Transfer-Encoding: quoted-printable Message-Id: <775CA5CF-27DF-4495-9FFF-0A0C3A650F87@linux.dev> References: <20260517123428.1181981-4-thorsten.blum@linux.dev> <20260517123428.1181981-5-thorsten.blum@linux.dev> To: Lorenzo Stoakes X-Migadu-Flow: FLOW_OUT (My apologies for the earlier HTML encoding.) As with Lorenzo's concerns, my biggest issue with this change is that it becomes unclear what "page" means in this context. Is it a base PAGE_SIZE page? A 2 MB "large" page? A 1 GB "huge" page on architectures that support it? The "rest_of_page()" macro masks that distinction, where the current = code=E2=80=99s explicit reference to PAGE_SIZE makes the basis of the calculation = obvious. I don=E2=80=99t see why we would want to obscure that behind a macro, = especially when it makes the code harder to follow. Thanks, Bill > On May 18, 2026, at 04:23, Lorenzo Stoakes wrote: >=20 > On Mon, May 18, 2026 at 09:48:32AM +0300, Andy Shevchenko wrote: >> On Sun, May 17, 2026 at 11:28:05AM -0400, Yury Norov wrote: >>> On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote: >>=20 >> ... >>=20 >>> I've got a series for this >>>=20 >>> https://lore.kernel.org/all/20260303182845.250bb2de@kernel.org/ >>>=20 >>> The feedback is surprisingly negative. Please add people from that >>> thread. Maybe you'll be more successful convincing them. >=20 > There's a cost to adding yet more super-specific headers where stuff = gets hidden > and people don't know where to put what, things quickly become a mess = and header > dependencies are already a nightmare. >=20 > Also in the case of this helper, I don't see the value in adding a = vague, > untyped, confusingly-named macro when PAGE_SIZE - offset_in_page() is = perfectly > cromulent and clear in what it's doing? >=20 >>=20 >> We always can simply fork, but I truly do not understand the = pushback. >=20 > Well, be my guest? This isn't a hugely helpful or friendly comment. >=20 >> These are simple macros that are way spread in the kernel, "include = everything" >> kinda linux/mm.h is not needed in vast majority of the users, hence = the >> split is logical step. >=20 > Right but that's completely orthogonal to adding this macro? >=20 > I'm fine with moving offset_in_page() to e.g. mm_types.h. >=20 > But a series that doesn't even give any actual motivation for the = change is not > convicing, and we aren't required to just accept any change. >=20 >>=20 >> I'm in favour of this series. >=20 > OK, I'm not :) >=20 >>=20 >> -- >> With Best Regards, >> Andy Shevchenko >>=20 >>=20 >=20 > Thanks, Lorenzo >=20