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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Feb 17, 2026 at 02:21:30PM +0000, Ryan Roberts 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.

That's a broken "qualification system" if that is the case, given that
the patches that flow back into stable kernel releases should be
triggering "full qualification" if anyone actually paid attention to
what goes into there :)

Anyway, good luck!  And same for 6.1.y, if they are ok with 6.6.y, why
would they even care about 6.1.y?

thanks,

greg k-h