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

[Ryan Roberts <ryan.roberts@arm.com>]

On 17/02/2026 14:26, Greg KH wrote:
> 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?

The request was only for 6.1. I did 6.6 as well for continuity; I didn't want it
to get slow again if they moved from 6.1 to 6.6. It's already fixed in 6.12.


> 
> thanks,
> 
> greg k-h