arch/arm64/include/asm/pgtable.h | 7 ++- arch/arm64/mm/mmu.c | 92 ++++++++++++++++++-------------- 2 files changed, 57 insertions(+), 42 deletions(-)
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. Thanks, Ryan Ryan Roberts (3): arm64: mm: Don't remap pgtables per-cont(pte|pmd) block arm64: mm: Batch dsb and isb when populating pgtables arm64: mm: Don't remap pgtables for allocate vs populate arch/arm64/include/asm/pgtable.h | 7 ++- arch/arm64/mm/mmu.c | 92 ++++++++++++++++++-------------- 2 files changed, 57 insertions(+), 42 deletions(-) -- 2.43.0
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? thanks, greg k-h
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. Thanks, Ryan > > thanks, > > greg k-h
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? thanks, greg k-h
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. > > thanks, > > greg k-h
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
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
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@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. 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 >
On Tue, Feb 17, 2026 at 10:21 PM Ryan Roberts <ryan.roberts@arm.com> 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. Why can't they use the kernel from bookworm-backports, which is 6.12? ChenYu
On Tue, Feb 17, 2026 at 10:27:53PM +0800, Chen-Yu Tsai wrote: > > On Tue, Feb 17, 2026 at 10:21 PM Ryan Roberts <ryan.roberts@arm.com> 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. > > Why can't they use the kernel from bookworm-backports, which is 6.12? Bookworm-backports will likely be our recommendation should this patchset ultimately be rejected. Debian 12 uses 6.1.y by default. While 6.12.y is available for that release via the bookworm-backports repository, bookworm-backports content is not generally recommended for production usage. It's not necessarily updated on the same cadence as the 6.1.y packages, and Debian does not publish security advisories for it. Debian does not want to maintain this change as a downstream patch, which is fair. Microsoft would like to make this boot optimization available by default to Debian 12 users (of which there are still many) which is why we're pursuing this path. Naturally, we'll manage if we can't get the change applied to 6.1.y, but hopefully this explains where we're coming from. noah
© 2016 - 2026 Red Hat, Inc.