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

[Ryan Roberts]

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.

> 
> thanks,
> 
> greg k-h