From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C9C82288B1 for ; Sat, 9 May 2026 00:12:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778285572; cv=none; b=r+JSFrJHUafG9mcWYHcy/0GTU9KJf2kRsU+tYQYspWMvJS9qAzYe6Kz3nRihUqKgxS20SAaJ0Oj7gJrC5PR9VRrZnaib+z5PHAZMHZH92HxdEp2OWwbb1jwbOz28897Re1FNP14BPhX/rLub6uvn5tAwI2El6hJM0jYfxNi0/C0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778285572; c=relaxed/simple; bh=Y0PS00zVL4JN6wHBq10JZ6+2omlC70GREkX6WSUksig=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=CsiEJqdm895fgx8iUWUdA8QdPuaZygUckOWzuMLuSKCreoiXuvWRW2bPiPXXR2bYYLxeXObbVooJ28YfKKFx/qC4lMeEEftEWDFUlWTtqBWUn0pX1S2mO29KaJJ2oX9KogtA56na1UiUKWvZUaIHyMPD84ghKpZtABC9W4Ltxtw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=G3D+otWk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="G3D+otWk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D500C2BCB0; Sat, 9 May 2026 00:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1778285572; bh=Y0PS00zVL4JN6wHBq10JZ6+2omlC70GREkX6WSUksig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=G3D+otWkjpEuuOmYB9k6qKoX2/m1kh+SDQ8/IJ4U6pOo/FlflrGKj1i/87XmCGiCi lNqFQbBPR3mFs4hcxoCtX+7UxGvD5eReymZcVnxZVx5vfNUjrZeXu+jImmVMJT6Jql t6SsS16mOv/q7wbqnJSgjlnRBfKu7qHH3rIueFC4= Date: Fri, 8 May 2026 17:12:51 -0700 From: Andrew Morton To: Hao Ge Cc: Suren Baghdasaryan , Kent Overstreet , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5] mm/alloc_tag: replace fixed-size early PFN array with dynamic linked list Message-Id: <20260508171251.9bfb5e833859090d4480e222@linux-foundation.org> In-Reply-To: <20260506022256.32664-1-hao.ge@linux.dev> References: <20260506022256.32664-1-hao.ge@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 6 May 2026 10:22:56 +0800 Hao Ge wrote: > Pages allocated before page_ext is available have their codetag left > uninitialized. Track these early PFNs and clear their codetag in > clear_early_alloc_pfn_tag_refs() to avoid "alloc_tag was not set" > warnings when they are freed later. > > Currently a fixed-size array of 8192 entries is used, with a warning if > the limit is exceeded. However, the number of early allocations depends > on the number of CPUs and can be larger than 8192. > > Replace the fixed-size array with a dynamically allocated linked list > of pfn_pool structs. Each node is allocated via alloc_page() and mapped > to a pfn_pool containing a next pointer, an atomic slot counter, and a > PFN array that fills the remainder of the page. > > The tracking pages themselves are allocated via alloc_page(), which > would trigger __pgalloc_tag_add() -> alloc_tag_add_early_pfn() and > recurse indefinitely. Introduce __GFP_NO_CODETAG (reuses the > %__GFP_NO_OBJ_EXT bit) and pass gfp_flags through pgalloc_tag_add() > so that the early path can skip recording allocations that carry this > flag. AI review asked a couple of things. I have a feeling we saw at least one of these, so probably already dealt with. https://sashiko.dev/#/patchset/20260506022256.32664-1-hao.ge@linux.dev