From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 7E69A39CCE8 for ; Mon, 3 Aug 2026 06:38:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785739118; cv=none; b=AnZo9JmJ4SUlzEho2QYifUluf8JQE0q1uuxHfkVku6K2bK/vbRTEwrktaHeYWxqxgKxl9aZmpv17RNZZde9LsvdlJm8E4b125pENHBqNs4KprImshb0p6IlS6OCro0s+TpZUFZgZXCyvY3KsGu0nrkKwkXBI+1tbYjcskH+R3LI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785739118; c=relaxed/simple; bh=EPo7D2LTqbFvobpaLEScBVPhfDblhQ+dJrnA25ncdlI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Mx5VxKNDV7OW5QCPmWQ9z9l2BxfONPV0uJmJ5BKNkgE6mXwvOhlk0vc6yf5aqlC1PesnR2c1tRy7XA81RULS09GoCL9b8COTuy3lVo9UgVnCreYD9xBXObeL1aQ9zWAQL0gM/qMdpHmMruJKBXJGjihtaGo3GYUyRlsZKoz0pfc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OW+F7WyO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OW+F7WyO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55AFC1F000E9; Mon, 3 Aug 2026 06:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785739117; bh=pW7Og0qPxzuL6m6WFYbBCbPX3qINoEYxL05Tp/X8L/M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OW+F7WyOx6cgS/hdYImcNWyD/FWqnkb/95WncioGVZSrVnsUcNUvp92NfVhJ3mYoT NVCBG4M5JTgSZ6cBMNXMo8GzMtXYoXDo5FPb0iGBya4dkVax7s/1NM1vS2jAcXx8oa w9fv/ZwElNMPHpK3zjsi95HROpgQDJGKazTOGhKIAR1ZAYNbvid5sgaBMAa4Vc7Y3E c//cStuusvoomu2ZXRFS2Yf+xT1zDCawUD85QNiZnrMLeSWXhD6MoUsbnOls8eKL7C Mv39sE6fO10OJfecIzohY6qmDcbUlE4MMLvqytBlOjWE/o1rIJgKUVqrhXY2nWG600 4x8LLeg8D2MwA== Date: Mon, 3 Aug 2026 09:38:31 +0300 From: Mike Rapoport To: Muchun Song 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 Subject: Re: [PATCH v2 03/17] mm/mm_init: skip initializing shared vmemmap tail pages Message-ID: 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> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <89878C33-9BCD-4FD7-92A0-884CF682CBF3@linux.dev> On Fri, Jul 31, 2026 at 10:13:43AM +0800, Muchun Song wrote: > > On Jul 30, 2026, at 22:32, Mike Rapoport wrote: > >> > >> Since we also use __pfn_to_section in the patch 14 in this series for > >> !SPARSEMEM, we need to make corresponding adjustments—specifically, 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. > > > > Do you mean that section_vmemmap_optimizable() will receive pfn as a > > parameter and use pfn_to_section_order() internally? > > 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. > > So I started thinking about an alternative. How about we keep section_vmemmap_optimizable() > as it is, but introduce a new helper like this: > > static inline bool order_vmemmap_optimizable(unsigned int order) > { > return order >= OPTIMIZABLE_FOLIO_MIN_ORDER; > } Maybe name it vmemmap_optimizable_order() so it'll belong to vmemmap namespace, order_ can be really a lot of things. I think it makes sense. Let's see how it fits in the end in the new version :) -- Sincerely yours, Mike.