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

[Ryan Roberts]

On 17/02/2026 14:43, Ryan Roberts wrote:
> 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@xxxxxxx/
>>>>>>>
>>>>>>> ... 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.

Hi Greg,

I thought a bit more about this overnight, and decided I wanted to have one more
go at convincing you...

In case you didn't read the commit logs, this series fixes a pretty nasty
performace bug; for a machine with 512G of RAM, it previously took 17.5 seconds
to create the linear map, and with the changes, it's down to 1.2 seconds. That's
quite a big quality-of-life improvement if you are booting VMs regularly.
(personally I hit this quite a bit).

It's a low risk change - it's been in since v6.10 and is part of arm64's core
boot path - and no issues have ever been raised.

Are you sure this isn't the sort of change that should be considered for stable?

Thanks,
Ryan


> 
> 
>>
>> thanks,
>>
>> greg k-h
>