On 17/02/2026 14:10, Greg KH wrote:

On Tue, Feb 17, 2026 at 01:58:36PM +0000, Ryan Roberts wrote:

quoted

On 17/02/2026 13:50, Greg KH wrote:

quoted

On Tue, Feb 17, 2026 at 01:34:05PM +0000, Ryan Roberts wrote:

quoted

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/ (local)

... 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