[PATCH 6.6 0/3] arm64: Speed up boot with faster linear map creation

[Noah Meyerhans]

On Tue, Feb 17, 2026 at 10:27:53PM +0800, Chen-Yu Tsai wrote:
> 
> On Tue, Feb 17, 2026 at 10:21 PM Ryan Roberts <ryan.roberts at arm.com> wrote:
> >
> > On 17/02/2026 14:10, Greg KH wrote:
> > > On Tue, Feb 17, 2026 at 01:58:36PM +0000, Ryan Roberts wrote:
> > >> On 17/02/2026 13:50, Greg KH wrote:
> > >>> On Tue, Feb 17, 2026 at 01:34:05PM +0000, Ryan Roberts wrote:
> > >>>> Hi All,
> > >>>>
> > >>>> This series is a backport that applies to stable kernel 6.6 (base v6.6.126), for
> > >>>> some speed ups to enable significantly faster booting on systems with a lot of
> > >>>> memory. The patches were originally posted at:
> > >>>>
> > >>>>   https://lore.kernel.org/linux-arm-kernel/20240412131908.433043-1-ryan.roberts@arm.com/
> > >>>>
> > >>>> ... and were originally merged upstream in v6.10-rc1.
> > >>>>
> > >>>> I'm requesting this be merged to stable on behalf of a partner who wants to get
> > >>>> the benefit of this series in Debian 12.
> > >>>
> > >>> Why can't they just use a newer kernel version (i.e. 6.12)?  Surely they
> > >>> would be able to justify moving to a newer kernel for performance
> > >>> reasons, why enable them to stay on an older one, just delaying the
> > >>> inevitable upgrade they will have to do anyway in a year or so?
> > >>
> > >> I can't answer this presicely, but I did ask and push for that approach. As I
> > >> understand it, they are stuck with Debian 12, which is stuck with kernel 6.1.
> > >> The Debian maintainer apparently requested that these go through stable in order
> > >> to get them into Debian 12.
> > >
> > > I understand the position of Debian not wanting to take patches for new
> > > features that are not already upstream, but really, Debian offers a
> > > newer kernel for hardware that wants to use it for things like this,
> > > right?  Why not just use that instead?
> >
> > Let me go push a bit harder. But I expect we are in the grey zone between bug
> > and feature here; this is a performance bug fix, not a new feature. By
> > selectively backporting I'm guessing they are avoiding the risk of new features
> > that a new kernel brings introducing new bugs? I'm guessing there is a higher
> > qualification bar for that.
> 
> Why can't they use the kernel from bookworm-backports, which is 6.12?

Bookworm-backports will likely be our recommendation should this
patchset ultimately be rejected.  Debian 12 uses 6.1.y by default.
While 6.12.y is available for that release via the bookworm-backports
repository, bookworm-backports content is not generally recommended for
production usage. It's not necessarily updated on the same cadence as
the 6.1.y packages, and Debian does not publish security advisories for
it.

Debian does not want to maintain this change as a downstream patch, 
which is fair.  Microsoft would like to make this boot optimization
available by default to Debian 12 users (of which there are still many)
which is why we're pursuing this path.  Naturally, we'll manage if we
can't get the change applied to 6.1.y, but hopefully this explains where
we're coming from.

noah