From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 7145A2F90C9 for ; Mon, 3 Aug 2026 06:46:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785739602; cv=none; b=LcdfRU42uDcrzMWoe5yk/rbMA5KIn83lwPFGCtHExgIXnL6GeEDktsEM9G3d0lTC4D8HTxtu0UMiWTb1+cPalYdZmkc3Y3WwP6FGl/pl3+mWrn5tSDMxM5CHMjG/AeBlXNU32opndQYMOHfmab0frI3f65fqj08diSdNCVmhdOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785739602; c=relaxed/simple; bh=aO9tuwdKHKZ8Wg+b2EYM4aekvM+mktiZsOpDrxly5yQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=cGGbgKdXHzEHg3ERR6S/devRcn+NHpqc0tAHQKPYv5Sg2Bv9qiHm/YMlx9L+Wnea8m27xGwn3+4M+YTVg9ZP4XnuvsDkgt8/Ue/AxmxTXqpdH/1+ZXfZzy1iMl0pY1Ny3rukZHQddjT3+StjWmQIIkKqTJLuGVh1+vc7h3yQ9AQ= 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=P2oSw2dU; arc=none smtp.client-ip=91.218.175.171 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="P2oSw2dU" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785739599; 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=UmJFN8HW2e7z7J1Q30SN59Y3ChlpGFjfWu2UBe0079g=; b=P2oSw2dUQu9uGbTRjarEu8AV0+4aQVTiU9fcPvIOr06lAFspuSL2Jt+/d2+TbXxim1KHE/ UhyAHtrSVFKq46YQo/wfu7sjattm+lTcumzjpsCLYqg/czVqwPHO5HSvut6YBZqkobnL2C vF39VbsfssqGE9Eb89JXaoRhC1zpnEk= 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 v2 03/17] mm/mm_init: skip initializing shared vmemmap tail pages X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Mon, 3 Aug 2026 14:45:55 +0800 Cc: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand , Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , David Laight , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <4FB096F3-80EC-4FD3-B859-4AF3162AABB2@linux.dev> References: <20260720093127.540540-1-songmuchun@bytedance.com> <20260720093127.540540-4-songmuchun@bytedance.com> <5005C7D3-B3ED-4C62-B611-8465D2BC69FD@linux.dev> <178540851830.2154539.6359871825839331816.b4-reply@b4> <3FCC8989-95DB-450F-95C3-183787DF4D08@linux.dev> <89878C33-9BCD-4FD7-92A0-884CF682CBF3@linux.dev> To: Mike Rapoport X-Migadu-Flow: FLOW_OUT > On Aug 3, 2026, at 14:38, Mike Rapoport wrote: >=20 > On Fri, Jul 31, 2026 at 10:13:43AM +0800, Muchun Song wrote: >>> On Jul 30, 2026, at 22:32, Mike Rapoport wrote: >>>>=20 >>>> Since we also use __pfn_to_section in the patch 14 in this series = for >>>> !SPARSEMEM, we need to make corresponding = adjustments=E2=80=94specifically, by using >>>> pfn_to_section_order to determine whether the vmemmap of a given = section is >>>> optimizable. This new helper will be called from several places, so = I'm afraid >>>> its introduction is unavoidable. >>>=20 >>> Do you mean that section_vmemmap_optimizable() will receive pfn as a >>> parameter and use pfn_to_section_order() internally? >>=20 >> I was originally planning to go with the this approach, but now I've = come across >> something that feels a bit unusual to me: a function whose name = starts with section >> takes a pfn as its argument instead of a mem_section. >>=20 >> So I started thinking about an alternative. How about we keep = section_vmemmap_optimizable() >> as it is, but introduce a new helper like this: >>=20 >> static inline bool order_vmemmap_optimizable(unsigned int order) >> { >> return order >=3D OPTIMIZABLE_FOLIO_MIN_ORDER; >> } >=20 > Maybe name it vmemmap_optimizable_order() so it'll belong to vmemmap > namespace, order_ can be really a lot of things. Make sense. >=20 > I think it makes sense. Let's see how it fits in the end in the new > version :) I'll update it as soon as possible. Muchun, Thanks. >=20 > --=20 > Sincerely yours, > Mike.