[TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

High memory is one of the least popular features of the Linux kernel.
Added in 1999 for linux-2.3.16 to support large x86 machines, there
are very few systems that still need it. I talked about about this
recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
and there were a few older discussions before[4][5][6].

While removing a feature that is actively used is clearly a regression
and not normally done, I expect removing highmem is going to happen
at some point anyway when there are few enough users, but the question
is when that time will be.

I'm still collecting information about which of the remaining highmem
users plan to keep updating their kernels and for what reason. Some
users obviously are alarmed about potentially losing this ability,
so I hope to get a broad consensus on a specific timeline for how long
we plan to support highmem in the page cache and to give every user
sufficient time to migrate to a well-tested alternative setup if that
is possible, or stay on a highmem-enabled LTS kernel for as long
as necessary.

These are the assumptions I'm making, based on both what I have
presented in my talk and feedback I have received so far, let me
know if something is missing here:

- Highmem in new kernels is almost exclusively an embedded Linux
  topic. While there were a few late 32-bit desktop and laptop
  systems that had more than 2GB of RAM, these were fairly short
  lived and have long been unsupported by both the originally
  shipping operating systems and most Linux distros. Notable
  Examples include Pentium 4 "Northwood" desktops (sold 2003-2004),
  Core Duo laptops (2006-2007), and Arm Chromebooks (rk3288,
  Tegra k1, Exynos 5800, sold 2014-2017). Some PowerPC G4 Macs
  and Atom Netbooks could be upgraded to 2GB.
  There are a small number of users, but they really love these
  devices and want to keep them alive, especially since they
  mark the peak of the respective 32-bit product lines.

- Within the embedded market, highmem is mostly used on ARMv7
  based SoCs, but a few others also need it and still get kernel
  updates:
  PowerPC 85xx, 86xx and QoriQ P1/P2/P3/P4 (produced 2003-2021)
  were used in some long-lived embedded systems with 2GB of RAM
  or more. Mediatek MT7621 (MIPS32r3, introduced 2014 but still
  sold) needs highmem to reach the upper 64MB of the 512MB physical
  memory. Ingenic JZ4780 (MIPS32, released 2012) was used in the
  short-lived MIPS Creator CI20 with 1GB of RAM (256MB lowmem)
  and probably othes. Sparc32/LEON seems to be limited to 192MB of
  lowmem as a kernel design choice. Vortex86DX3 supports 2GB
  DDR3 memory.
  The kernel also supports highmem on ARMv4, ARMv5, ARMv6,
  PPC4xx, PPC82xx, PPC83xx, ARC, CSKY, Microblaze and Xtensa,
  as well as additional MIPS SoCs,  but so far I could not find
  any indication of any such machine with more than 1GB that
  keeps getting kernel updates.

- The vast majority of new embedded ARMv7 machines have 1GB of
  RAM or less, which on many SoCs is a physical limitation
  a narrow DDR3 memory interface, as well as a cost tradeoff.
  The 1GB case is interesting because that usually means having
  only 768MB of lowmem plus 256MB of highmem, as well as 3GB
  of virtual addressing. I expect that almost all applications
  on these work just as well with CONFIG_VMSPLIT_3G_OPT, changing
  the limit to 1GB of lowmem and 2816MB of user address space.
  The same thing should work on x86 and powerpc (CONFIG_LOWMEM_SIZE)
  but not on mips and sparc where the limit is not configurable.

- A few Arm SoCs have sparse physical address ranges for
  their RAM, e.g. range per memory controllers like the Renesas
  R-Car Gen 2 or Broadcom BCM4708. These currently require highmem
  even on configurations with less than 1GB RAM, until we change
  the way that sparsemem is handled to support rearranging the
  linear map to fill all of lowmem. This still needs more work.

- ARMv7 machines with 2GB remain in production, in particular
  with the popular i.MX6Dual/Quad chip that has a 64-bit wide DDR3
  interface and guaranteed manufacturer support until 2035.
  This is the configuration I expect to see struggle the most.
  Setting CONFIG_VMSPLIT_2G or CONFIG_VMSPLIT_2G_OPT should work
  for most of the users but can break if an application runs out
  of virtual address space, so this does require extensive testing,
  and possibly user space changes. An example of possibly affected
  userspace is Firefox, which needs more address space than other
  applications but can perhaps be replaced with another embedded
  browser.
  
- ARMv7 machines with 4GB and more exist and keep getting
  kernel upgrades, but to my knowledge are not in production any
  more. These are mainly 2010-2015 era chips based on rare
  out-of-order cores like A15, A17 or PJ4 that were designed for
  low-end servers, chromebooks and network equipment but replaced
  with 64-bit chips shortly after. We had planned to bring a
  CONFIG_VMSPLIT_4G_4G option to ARMv7VE to keep supporting the full
  memory at a performance penalty, but currently have no plan to
  finish this (volunteers welcome).
  There is still some hope to keep them working with a combination
  of CONFIG_VMSPLIT_2G and a modified ZRAM that can use high
  pages without CONFIG_HIGHMEM, but whether this works depends
  a lot on the application. I expect most of these products to
  stop getting kernel updates in the next few years due to aging
  hardware and increasing cost for updating out-of-tree patches
  on platforms that are not fully upstream. I do not remember any
  such devices with official support beyond 2030.

My proposal based on the above assumptions is to gradually phase
out highmem over the next 2 years for mainline kernels, obviously
both the individual items and the timeline are completely up for
debate:

1. mark CONFIG_HIGHMEM as 'depends on EXPERT', updating the
   Kconfig description to point to the kernel summit discussion
   any any decisions made here.

2. Change the ARMv7 Kconfig defaults to CONFIG_VMSPLIT_3G_OPT
   and HIGHMEM=n, to make it more likely to find possible
   regressions with that, without changing much for users.
   Possibly do the same for x86 and powerpc.

3. Start removing __GFP_HIGHMEM from in-kernel allocations
   other than the page cache, in particular from individual
   device drivers and filesystem metadata where there is
   already little benefit.

4. Remove HIGHMEM as an option from platforms that are thought
   to no longer need it (arc, armv5, ppc4xx, ppc82xx, ppc83xx,
   csky, microblaze, xtensa), mainly to validate the
   assertion that these use only lowmem.

5. Split highmem on zram out into a separate Kconfig option
   that can be enabled without CONFIG_HIGHMEM or CONFIG_EXPERT

6. Finish the "densemem" replacement for sparsemem, ideally
   allowing both very sparse lowmem areas and a boot-time
   vmsplit selection instead of the compile-time one.

7. Finally, remove the highmem pagecache option, leaving only
   zram and custom device drivers as a way to access high
   pages.

That last step should wait for an LTS kernel, ideally a version
that the CIP project's SLTS kernel is planning to keep supporting
for 10 years. The newest SLTS kernel was 6.12 last year, and the
phb-crytal-ball suggests that the next one in December 2026 may
be linux-7.4, the one after that in December 2028 (linux-7.15?)
seems too far out to plan for but would be another option.

Unless there is an easy consensus on this on the mailing list,
I would like to lead a discussion session at the kernel summit
in order to get closer to a decision.

     Arnd 

[1] https://osseu2025.sched.com/event/25VmZ/32-bit-linux-support-now-and-in-the-future-arnd-bergmann-linaro
[2] https://www.youtube.com/watch?v=QiOMiyGCoTw
[3] https://lwn.net/Articles/1035727/
[4] https://lore.kernel.org/all/0047f565-ada4-491a-b157-f2d8dfde0ac0@app.fastmail.com/
[5] https://lwn.net/Articles/813201/
[6] https://lpc.events/event/16/contributions/1183/attachments/1062/2028/highmem-api-2022-09-12.pdf

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[H. Peter Anvin]

On September 9, 2025 2:23:37 PM PDT, Arnd Bergmann <arnd@arndb.de> wrote:
>High memory is one of the least popular features of the Linux kernel.
>Added in 1999 for linux-2.3.16 to support large x86 machines, there
>are very few systems that still need it. I talked about about this
>recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
>and there were a few older discussions before[4][5][6].
>
>While removing a feature that is actively used is clearly a regression
>and not normally done, I expect removing highmem is going to happen
>at some point anyway when there are few enough users, but the question
>is when that time will be.
>
>I'm still collecting information about which of the remaining highmem
>users plan to keep updating their kernels and for what reason. Some
>users obviously are alarmed about potentially losing this ability,
>so I hope to get a broad consensus on a specific timeline for how long
>we plan to support highmem in the page cache and to give every user
>sufficient time to migrate to a well-tested alternative setup if that
>is possible, or stay on a highmem-enabled LTS kernel for as long
>as necessary.
>
>These are the assumptions I'm making, based on both what I have
>presented in my talk and feedback I have received so far, let me
>know if something is missing here:
>
>- Highmem in new kernels is almost exclusively an embedded Linux
>  topic. While there were a few late 32-bit desktop and laptop
>  systems that had more than 2GB of RAM, these were fairly short
>  lived and have long been unsupported by both the originally
>  shipping operating systems and most Linux distros. Notable
>  Examples include Pentium 4 "Northwood" desktops (sold 2003-2004),
>  Core Duo laptops (2006-2007), and Arm Chromebooks (rk3288,
>  Tegra k1, Exynos 5800, sold 2014-2017). Some PowerPC G4 Macs
>  and Atom Netbooks could be upgraded to 2GB.
>  There are a small number of users, but they really love these
>  devices and want to keep them alive, especially since they
>  mark the peak of the respective 32-bit product lines.
>
>- Within the embedded market, highmem is mostly used on ARMv7
>  based SoCs, but a few others also need it and still get kernel
>  updates:
>  PowerPC 85xx, 86xx and QoriQ P1/P2/P3/P4 (produced 2003-2021)
>  were used in some long-lived embedded systems with 2GB of RAM
>  or more. Mediatek MT7621 (MIPS32r3, introduced 2014 but still
>  sold) needs highmem to reach the upper 64MB of the 512MB physical
>  memory. Ingenic JZ4780 (MIPS32, released 2012) was used in the
>  short-lived MIPS Creator CI20 with 1GB of RAM (256MB lowmem)
>  and probably othes. Sparc32/LEON seems to be limited to 192MB of
>  lowmem as a kernel design choice. Vortex86DX3 supports 2GB
>  DDR3 memory.
>  The kernel also supports highmem on ARMv4, ARMv5, ARMv6,
>  PPC4xx, PPC82xx, PPC83xx, ARC, CSKY, Microblaze and Xtensa,
>  as well as additional MIPS SoCs,  but so far I could not find
>  any indication of any such machine with more than 1GB that
>  keeps getting kernel updates.
>
>- The vast majority of new embedded ARMv7 machines have 1GB of
>  RAM or less, which on many SoCs is a physical limitation
>  a narrow DDR3 memory interface, as well as a cost tradeoff.
>  The 1GB case is interesting because that usually means having
>  only 768MB of lowmem plus 256MB of highmem, as well as 3GB
>  of virtual addressing. I expect that almost all applications
>  on these work just as well with CONFIG_VMSPLIT_3G_OPT, changing
>  the limit to 1GB of lowmem and 2816MB of user address space.
>  The same thing should work on x86 and powerpc (CONFIG_LOWMEM_SIZE)
>  but not on mips and sparc where the limit is not configurable.
>
>- A few Arm SoCs have sparse physical address ranges for
>  their RAM, e.g. range per memory controllers like the Renesas
>  R-Car Gen 2 or Broadcom BCM4708. These currently require highmem
>  even on configurations with less than 1GB RAM, until we change
>  the way that sparsemem is handled to support rearranging the
>  linear map to fill all of lowmem. This still needs more work.
>
>- ARMv7 machines with 2GB remain in production, in particular
>  with the popular i.MX6Dual/Quad chip that has a 64-bit wide DDR3
>  interface and guaranteed manufacturer support until 2035.
>  This is the configuration I expect to see struggle the most.
>  Setting CONFIG_VMSPLIT_2G or CONFIG_VMSPLIT_2G_OPT should work
>  for most of the users but can break if an application runs out
>  of virtual address space, so this does require extensive testing,
>  and possibly user space changes. An example of possibly affected
>  userspace is Firefox, which needs more address space than other
>  applications but can perhaps be replaced with another embedded
>  browser.
>  
>- ARMv7 machines with 4GB and more exist and keep getting
>  kernel upgrades, but to my knowledge are not in production any
>  more. These are mainly 2010-2015 era chips based on rare
>  out-of-order cores like A15, A17 or PJ4 that were designed for
>  low-end servers, chromebooks and network equipment but replaced
>  with 64-bit chips shortly after. We had planned to bring a
>  CONFIG_VMSPLIT_4G_4G option to ARMv7VE to keep supporting the full
>  memory at a performance penalty, but currently have no plan to
>  finish this (volunteers welcome).
>  There is still some hope to keep them working with a combination
>  of CONFIG_VMSPLIT_2G and a modified ZRAM that can use high
>  pages without CONFIG_HIGHMEM, but whether this works depends
>  a lot on the application. I expect most of these products to
>  stop getting kernel updates in the next few years due to aging
>  hardware and increasing cost for updating out-of-tree patches
>  on platforms that are not fully upstream. I do not remember any
>  such devices with official support beyond 2030.
>
>My proposal based on the above assumptions is to gradually phase
>out highmem over the next 2 years for mainline kernels, obviously
>both the individual items and the timeline are completely up for
>debate:
>
>1. mark CONFIG_HIGHMEM as 'depends on EXPERT', updating the
>   Kconfig description to point to the kernel summit discussion
>   any any decisions made here.
>
>2. Change the ARMv7 Kconfig defaults to CONFIG_VMSPLIT_3G_OPT
>   and HIGHMEM=n, to make it more likely to find possible
>   regressions with that, without changing much for users.
>   Possibly do the same for x86 and powerpc.
>
>3. Start removing __GFP_HIGHMEM from in-kernel allocations
>   other than the page cache, in particular from individual
>   device drivers and filesystem metadata where there is
>   already little benefit.
>
>4. Remove HIGHMEM as an option from platforms that are thought
>   to no longer need it (arc, armv5, ppc4xx, ppc82xx, ppc83xx,
>   csky, microblaze, xtensa), mainly to validate the
>   assertion that these use only lowmem.
>
>5. Split highmem on zram out into a separate Kconfig option
>   that can be enabled without CONFIG_HIGHMEM or CONFIG_EXPERT
>
>6. Finish the "densemem" replacement for sparsemem, ideally
>   allowing both very sparse lowmem areas and a boot-time
>   vmsplit selection instead of the compile-time one.
>
>7. Finally, remove the highmem pagecache option, leaving only
>   zram and custom device drivers as a way to access high
>   pages.
>
>That last step should wait for an LTS kernel, ideally a version
>that the CIP project's SLTS kernel is planning to keep supporting
>for 10 years. The newest SLTS kernel was 6.12 last year, and the
>phb-crytal-ball suggests that the next one in December 2026 may
>be linux-7.4, the one after that in December 2028 (linux-7.15?)
>seems too far out to plan for but would be another option.
>
>Unless there is an easy consensus on this on the mailing list,
>I would like to lead a discussion session at the kernel summit
>in order to get closer to a decision.
>
>     Arnd 
>
>[1] https://osseu2025.sched.com/event/25VmZ/32-bit-linux-support-now-and-in-the-future-arnd-bergmann-linaro
>[2] https://www.youtube.com/watch?v=QiOMiyGCoTw
>[3] https://lwn.net/Articles/1035727/
>[4] https://lore.kernel.org/all/0047f565-ada4-491a-b157-f2d8dfde0ac0@app.fastmail.com/
>[5] https://lwn.net/Articles/813201/
>[6] https://lpc.events/event/16/contributions/1183/attachments/1062/2028/highmem-api-2022-09-12.pdf
>

1 GB systems used highmem too, sadly. And 1 GB was the norm for a big chuck of the late 32-bit era.

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Linus Torvalds]

On Tue, 9 Sept 2025 at 14:39, H. Peter Anvin <hpa@zytor.com> wrote:
>
> 1 GB systems used highmem too, sadly. And 1 GB was the norm for a big chuck of the late 32-bit era.

Well, while on x86 1GB systems did use highmem, they'd typically not
use very much of it.

IOW, they'd have about 900MB as lowmem (ok, I think it was 896MB to be
exact), with something like 120MB highmem.

So they'd either lose a bit of memory, or they'd use the 2G:2G split.

Or - and I think this is the main point - they'd stay on old kernels
like the ancient museum pieces they are.

I'm not convinced it makes sense to have a modern kernel on a museum piece.

         Linus

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[H. Peter Anvin]

On September 9, 2025 3:24:29 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, 9 Sept 2025 at 14:39, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> 1 GB systems used highmem too, sadly. And 1 GB was the norm for a big chuck of the late 32-bit era.
>
>Well, while on x86 1GB systems did use highmem, they'd typically not
>use very much of it.
>
>IOW, they'd have about 900MB as lowmem (ok, I think it was 896MB to be
>exact), with something like 120MB highmem.
>
>So they'd either lose a bit of memory, or they'd use the 2G:2G split.
>
>Or - and I think this is the main point - they'd stay on old kernels
>like the ancient museum pieces they are.
>
>I'm not convinced it makes sense to have a modern kernel on a museum piece.
>
>         Linus
>

Certainly. And the 2:2 split is probably the right thing for the old machines anyway.

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[René Herman]

> Well, while on x86 1GB systems did use highmem, they'd typically not 
> use very much of it.
> 
> IOW, they'd have about 900MB as lowmem (ok, I think it was 896MB to
> be exact), with something like 120MB highmem.
> 
> So they'd either lose a bit of memory, or they'd use the 2G:2G
> split.
Right, 1G-128M of VMALLOC_RESERVE, but they didn't generally use 2G/2G 
but ever since it was introduced late in the 32-bit era VMSPLIT_3G_OPT, 
i.e., PAGE_OFFSET = 0xb0000000, i.e., 3G-256M/1G+256M.

Although at the time the patches died an unceremonious death, 4G/4G 
patches for x86 were also around; I used to be a (conceptual) fan of 
them: it takes quite a number of TLB-flushes to suck more than highmem.

Not one hint of clue if spectre/meltdown is applicable to these systems 
and if so, if they in fact do or should already be suffering through 
those same flushes anyway but maybe it'd be an option to dig those 
patches out of some archive somewhere.

I promise I'll test them on an AMD Duron with 768MB RAM :)

Rene.

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Matthew Wilcox]

On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
> While removing a feature that is actively used is clearly a regression
> and not normally done, I expect removing highmem is going to happen
> at some point anyway when there are few enough users, but the question
> is when that time will be.

I don't mind that the feature remains ... unless it causes us trouble.
Which it currently does.  Perhaps we could start by removing HIGHPTE?
There was a certain amount of complexity introduced into the page fault
path when support for that was introduced.  x86 removed support for it,
so it's just ARM left before we can remove the complexity again.

Most of the other pain points are around storing metadata (directories,
superblocks, etc) in page cache highmem.  I think we can get rid of that
now too.

I don't see any particular need to gt rid of file data stored in highmem,
nor anonymous memory stored in highmem.  And if we're only talking
about hundreds of megabytes of memory, I think anon+ file pagecache is
probably most of the memory in the system already unless you have some
very weird workloads.

Where we may want to be a bit careful is some people have Plans to
reuse the kmap infrastructure to support things like unmapping the
pagecacheto protect against spectre-eqsue attacks.  I know Intel was
working on this when 3dxp was going to be a Thing, but it's recently
been brought back:

https://lore.kernel.org/linux-mm/20250812173109.295750-1-jackmanb@google.com/

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Linus Walleij]

On Wed, Sep 10, 2025 at 3:46 AM Matthew Wilcox <willy@infradead.org> wrote:

> I don't mind that the feature remains ... unless it causes us trouble.
> Which it currently does.  Perhaps we could start by removing HIGHPTE?
> There was a certain amount of complexity introduced into the page fault
> path when support for that was introduced.  x86 removed support for it,
> so it's just ARM left before we can remove the complexity again.

I sent an RFC patch so we can see what Russell has to say about this,
it is currently only enabled by default on the VT8500 machine.

Yours,
Linus Walleij

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Wed, Sep 10, 2025, at 03:46, Matthew Wilcox wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>> While removing a feature that is actively used is clearly a regression
>> and not normally done, I expect removing highmem is going to happen
>> at some point anyway when there are few enough users, but the question
>> is when that time will be.
>
> I don't mind that the feature remains ... unless it causes us trouble.
> Which it currently does.  Perhaps we could start by removing HIGHPTE?
> There was a certain amount of complexity introduced into the page fault
> path when support for that was introduced.  x86 removed support for it,
> so it's just ARM left before we can remove the complexity again.
>
> Most of the other pain points are around storing metadata (directories,
> superblocks, etc) in page cache highmem.  I think we can get rid of that
> now too.

Agreed, this is roughly what I meant with the suggestion of removing
__GFP_HIGHMEM allocations from as many places as possible, while leaving
the pagecache and zram. I already brought up HIGHPTE earlier this year
since it already has an separate Kconfig symbol, but Russell was worried
about increasing the lowmem usage at all.

Maybe we could go back to the earlier idea of first categorizing
the important highmem users better, and make it possible to
use Kconfig symbols to enable highpte/highmem-anonymous/highmem-file/
highmem-metadata/highmem-zram/... individually as well as count the
actual usage for each of them. Having statistics in /proc/meminfo or
similar would allow more informed decision about no longer supporting
some of the categories later.

Not sure how many __GFP_ flags we could reasonably spend on categorizing,
as we are already up to 26 out of 32 (not counting CONFIG_ASAN_HW_TAGS,
which is 64-bit only and uses two more bits), or what alternative
would work.

> I don't see any particular need to gt rid of file data stored in highmem,
> nor anonymous memory stored in highmem.  And if we're only talking
> about hundreds of megabytes of memory, I think anon+ file pagecache is
> probably most of the memory in the system already unless you have some
> very weird workloads.

The main problem I see with the pagecache itself is that the fewer
highmem machines people test on, the harder it gets to spot regressions
where new code fails to kmap() the pages correctly.

Another concern is the number of memory zones, but it does not appear
that we would completely remove ZONE_HIGHMEM as long as ZRAM or pagecache
uses it.

> Where we may want to be a bit careful is some people have Plans to
> reuse the kmap infrastructure to support things like unmapping the
> pagecacheto protect against spectre-eqsue attacks.  I know Intel was
> working on this when 3dxp was going to be a Thing, but it's recently
> been brought back:
>
> https://lore.kernel.org/linux-mm/20250812173109.295750-1-jackmanb@google.com/

If that gets merged, it would at least address the concern about
testing, since presumably many bugs around missing kmap/kumap then
also show up on x86-64 kernels with ASI enabled.

    Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[David Hildenbrand]

On 10.09.25 14:17, Arnd Bergmann wrote:
> On Wed, Sep 10, 2025, at 03:46, Matthew Wilcox wrote:
>> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>>> While removing a feature that is actively used is clearly a regression
>>> and not normally done, I expect removing highmem is going to happen
>>> at some point anyway when there are few enough users, but the question
>>> is when that time will be.
>>
>> I don't mind that the feature remains ... unless it causes us trouble.
>> Which it currently does.  Perhaps we could start by removing HIGHPTE?
>> There was a certain amount of complexity introduced into the page fault
>> path when support for that was introduced.  x86 removed support for it,
>> so it's just ARM left before we can remove the complexity again.
>>
>> Most of the other pain points are around storing metadata (directories,
>> superblocks, etc) in page cache highmem.  I think we can get rid of that
>> now too.
> 
> Agreed, this is roughly what I meant with the suggestion of removing
> __GFP_HIGHMEM allocations from as many places as possible, while leaving
> the pagecache and zram. I already brought up HIGHPTE earlier this year
> since it already has an separate Kconfig symbol, but Russell was worried
> about increasing the lowmem usage at all.
> 
> Maybe we could go back to the earlier idea of first categorizing
> the important highmem users better, and make it possible to
> use Kconfig symbols to enable highpte/highmem-anonymous/highmem-file/
> highmem-metadata/highmem-zram/... individually as well as count the
> actual usage for each of them. Having statistics in /proc/meminfo or
> similar would allow more informed decision about no longer supporting
> some of the categories later.

That makes sense.

Essentially, let's move out as much of the 
now-possibly-unnecessary-complexity while still leaving basic highmem 
support in. To mean that implies removing highpte first.

> 
> Not sure how many __GFP_ flags we could reasonably spend on categorizing,
> as we are already up to 26 out of 32 (not counting CONFIG_ASAN_HW_TAGS,
> which is 64-bit only and uses two more bits), or what alternative
> would work.
> 
>> I don't see any particular need to gt rid of file data stored in highmem,
>> nor anonymous memory stored in highmem.  And if we're only talking
>> about hundreds of megabytes of memory, I think anon+ file pagecache is
>> probably most of the memory in the system already unless you have some
>> very weird workloads.
> 
> The main problem I see with the pagecache itself is that the fewer
> highmem machines people test on, the harder it gets to spot regressions
> where new code fails to kmap() the pages correctly.

Yes. Whenever I touch highmem I'm concerned I will silently break 
something and nobody notices.

Then I find myself booting a x86-pat in a VM and wonder why we are still 
supporting that and why it is so hard for me to get it tested. If we 
manage to not have that testing part so annoying, it would already eb a 
big win.

(did ever anybody look into simulating highmem on 64bit to make it 
easier to test?)

> 
> Another concern is the number of memory zones, but it does not appear
> that we would completely remove ZONE_HIGHMEM as long as ZRAM or pagecache
> uses it.
> 
>> Where we may want to be a bit careful is some people have Plans to
>> reuse the kmap infrastructure to support things like unmapping the
>> pagecacheto protect against spectre-eqsue attacks.  I know Intel was
>> working on this when 3dxp was going to be a Thing, but it's recently
>> been brought back:
>>
>> https://lore.kernel.org/linux-mm/20250812173109.295750-1-jackmanb@google.com/
> 
> If that gets merged, it would at least address the concern about
> testing, since presumably many bugs around missing kmap/kumap then
> also show up on x86-64 kernels with ASI enabled.

Right. Likely we should at some point cleanup the api to not talk about 
map/unmap but rather something along the lines of "start access / end 
access".

-- 
Cheers

David / dhildenb

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Linus Walleij]

On Tue, Sep 9, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:

> - ARMv7 machines with 4GB and more exist and keep getting
>   kernel upgrades, but to my knowledge are not in production any
>   more. These are mainly 2010-2015 era chips based on rare
>   out-of-order cores like A15, A17 or PJ4 that were designed for
>   low-end servers, chromebooks and network equipment but replaced
>   with 64-bit chips shortly after. We had planned to bring a
>   CONFIG_VMSPLIT_4G_4G option to ARMv7VE to keep supporting the full
>   memory at a performance penalty, but currently have no plan to
>   finish this (volunteers welcome).

I'll fill in on the details on that, because I tried, to the best of my
ability to prototype this but I failed, so far.

Here is what I managed to do:

1. Building on another rough prototype by Afzal Mohammed, I managed
to compile the ARM32 kernel into the VMALLOC area, this works
fine and here are the patches:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v6.10-rc1

This is is done so that we can unmap *most* of the kernel
memory but *keep* the VMALLOC area, so that e.g. exceptions
can still execute and save to stack when they occur, and we can
call into the kernel to execute said exceptions.

This in practice means the area 0xf1000000-0xffffffff
which also includes the high exception vectors that must for
natural reasons also be kept in the mapping.
What we have mapped today (all of the time) is
0xc0000000-0xffffffff.

A minimal 256 MB mapping from 0xf0000000-0xffffffff
should be able to cover this.

So when we are talking about a 4G/4G split we are talking
about (4G-256MB)/(4GB-256MB) split to be exact,
we would keep the bottom 256 MB.

2. On top of this I tried to decouple kernelspace and userspace
allocations, in essence making anything outside vmalloc invisible to
userspace by unmapping it using the fact that ARM32 (LPAE) has
two separate translation table base registers: one for kernelspace
and one for userspace.

Step 2 makes sense because we know the reverse can work:
PAN (privileged access never) makes userspace memory
inaccessible from kernelspace unless explicitly requested and
that works fine already, and we implemented it for LPAE
with similar trickery, see commit 7af5b901e847.

It's harder than it looks though and I never got it to fly, but
maybe I will try again. My patches is a mess but I am a bit
smarter now due to reoccurring MM-related work.

Yours,
Linus Walleij

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Richard Weinberger]

Arnd,

----- Ursprüngliche Mail -----
> Von: "Arnd Bergmann" <arnd@arndb.de>
> High memory is one of the least popular features of the Linux kernel.
> Added in 1999 for linux-2.3.16 to support large x86 machines, there
> are very few systems that still need it. I talked about about this
> recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
> and there were a few older discussions before[4][5][6].
> 
> While removing a feature that is actively used is clearly a regression
> and not normally done, I expect removing highmem is going to happen
> at some point anyway when there are few enough users, but the question
> is when that time will be.
> 
> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason. Some
> users obviously are alarmed about potentially losing this ability,
> so I hope to get a broad consensus on a specific timeline for how long
> we plan to support highmem in the page cache and to give every user
> sufficient time to migrate to a well-tested alternative setup if that
> is possible, or stay on a highmem-enabled LTS kernel for as long
> as necessary.

I am part of a team responsible for products based on various 32-bit SoCs,
so I'm alarmed.
These products, which include ARMv7 and PPC32 architectures with up to 2 GiB of RAM,
are communication systems with five-figure deployments worldwide.

Removing high memory will have an impact on these systems.
The oldest kernel version they run is 4.19 LTS, with upgrades to a more recent
LTS release currently in progress.
We typically upgrade the kernel every few years and will continue to support
these systems for at least the next 10 years.

Even with a new memory split, which could utilize most of the available memory,
I expect there to be issues with various applications and FPGA device drivers.

Thanks,
//richard

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Matthew Wilcox]

On Wed, Sep 10, 2025 at 03:10:05PM +0200, Linus Walleij wrote:
> This is is done so that we can unmap *most* of the kernel
> memory but *keep* the VMALLOC area, so that e.g. exceptions
> can still execute and save to stack when they occur, and we can
> call into the kernel to execute said exceptions.
> 
> This in practice means the area 0xf1000000-0xffffffff
> which also includes the high exception vectors that must for
> natural reasons also be kept in the mapping.
> What we have mapped today (all of the time) is
> 0xc0000000-0xffffffff.
> 
> A minimal 256 MB mapping from 0xf0000000-0xffffffff
> should be able to cover this.

Can I ask where the MMIO (PCI?) window lives?

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Wed, Sep 10, 2025, at 16:04, Matthew Wilcox wrote:
> On Wed, Sep 10, 2025 at 03:10:05PM +0200, Linus Walleij wrote:
>> 
>> This in practice means the area 0xf1000000-0xffffffff
>> which also includes the high exception vectors that must for
>> natural reasons also be kept in the mapping.
>> What we have mapped today (all of the time) is
>> 0xc0000000-0xffffffff.
>> 
>> A minimal 256 MB mapping from 0xf0000000-0xffffffff
>> should be able to cover this.
>
> Can I ask where the MMIO (PCI?) window lives?

That 256MB area is shared by anything the kernel can access
directly, other than the linear map: vmlinux, modules, vmalloc,
ioremap, vmap-stack, etc.

This is mostly unchanged from the tradtitional layout on
arm32 that has the same ~256MB limitation, though it does
get a little tighter because .text/.data is now also
mapped into this space instead of executed from the linear
map.

      ARnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Dave Hansen]

On 9/10/25 07:04, Richard Weinberger wrote:
> I am part of a team responsible for products based on various 32-bit
> SoCs, so I'm alarmed. These products, which include ARMv7 and PPC32
> architectures with up to 2 GiB of RAM, are communication systems
> with five-figure deployments worldwide.
> 
> Removing high memory will have an impact on these systems. The
> oldest kernel version they run is 4.19 LTS, with upgrades to a more
> recent LTS release currently in progress. We typically upgrade the
> kernel every few years and will continue to support these systems
> for at least the next 10 years.
> 
> Even with a new memory split, which could utilize most of the
> available memory, I expect there to be issues with various
> applications and FPGA device drivers.
I'd be really curious what the _actual_ issues would be with a
non-standard split. There are a lot of "maybe" problems and solutions
here, but it's hard to move forward without known practical problems to
tackle.

Has anybody run into actual end user visible problems when using one of
weirdo PAGE_OFFSET configs?

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Christophe Leroy]

Hi Richard,

Le 10/09/2025 à 16:04, Richard Weinberger a écrit :
> Arnd,
> 
> ----- Ursprüngliche Mail -----
>> Von: "Arnd Bergmann" <arnd@arndb.de>
>> High memory is one of the least popular features of the Linux kernel.
>> Added in 1999 for linux-2.3.16 to support large x86 machines, there
>> are very few systems that still need it. I talked about about this
>> recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
>> and there were a few older discussions before[4][5][6].
>>
>> While removing a feature that is actively used is clearly a regression
>> and not normally done, I expect removing highmem is going to happen
>> at some point anyway when there are few enough users, but the question
>> is when that time will be.
>>
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason. Some
>> users obviously are alarmed about potentially losing this ability,
>> so I hope to get a broad consensus on a specific timeline for how long
>> we plan to support highmem in the page cache and to give every user
>> sufficient time to migrate to a well-tested alternative setup if that
>> is possible, or stay on a highmem-enabled LTS kernel for as long
>> as necessary.
> 
> I am part of a team responsible for products based on various 32-bit SoCs,
> so I'm alarmed.
> These products, which include ARMv7 and PPC32 architectures with up to 2 GiB of RAM,
> are communication systems with five-figure deployments worldwide.
> 
> Removing high memory will have an impact on these systems.
> The oldest kernel version they run is 4.19 LTS, with upgrades to a more recent
> LTS release currently in progress.
> We typically upgrade the kernel every few years and will continue to support
> these systems for at least the next 10 years.
> 
> Even with a new memory split, which could utilize most of the available memory,
> I expect there to be issues with various applications and FPGA device drivers.

Can you tell which PPC32 model/family you are using ? Is it mpc85xx or 
and/or other variants ? Maybe we can look at keeping CONFIG_HIGHMEM or 
find alternatives for that subset of PPC32 only.

Could you also elaborate a bit on the kind of issues you forsee or fear 
with applications and FPGA device drivers.

FWIW I sent out today a patch that removes CONFIG_HIGHMEM complely on 
powerpc in order to get a better view of the impacted areas and allow 
people to test what it looks like on their system without 
CONFIG_HIGHMEM. See [1].

Christophe

[1] 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/28d908b95fe358129db18f69b30891788e15ada0.1757512010.git.christophe.leroy@csgroup.eu/

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Richard Weinberger]

Christophe,

----- Ursprüngliche Mail -----
> Von: "Christophe Leroy" <christophe.leroy@csgroup.eu>
> Can you tell which PPC32 model/family you are using ? Is it mpc85xx or
> and/or other variants ? Maybe we can look at keeping CONFIG_HIGHMEM or
> find alternatives for that subset of PPC32 only.

Off the head, MPC8343 and QorIQ P1022.

> 
> Could you also elaborate a bit on the kind of issues you forsee or fear
> with applications and FPGA device drivers.

Unfortunately, applications in this area often make certain assumptions
about the amount or layout of memory. This becomes a bigger problem when
using FPGA device drivers of questionable quality, which share memory
between the kernel, userspace, and the device itself.
These are mostly out-of-tree drivers, so that's my horse to ride, 
I'm just mentally preparing myself for "interesting" bugs that will need
to be sorted out.

> FWIW I sent out today a patch that removes CONFIG_HIGHMEM complely on
> powerpc in order to get a better view of the impacted areas and allow
> people to test what it looks like on their system without
> CONFIG_HIGHMEM. See [1].

Oh, that was fast. :-)

Thanks,
//richard

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Richard Weinberger]

Dave,

----- Ursprüngliche Mail -----
> Von: "Dave Hansen" <dave@sr71.net>
>> Even with a new memory split, which could utilize most of the
>> available memory, I expect there to be issues with various
>> applications and FPGA device drivers.
> I'd be really curious what the _actual_ issues would be with a
> non-standard split. There are a lot of "maybe" problems and solutions
> here, but it's hard to move forward without known practical problems to
> tackle.
> 
> Has anybody run into actual end user visible problems when using one of
> weirdo PAGE_OFFSET configs?

In the past I saw that programs such as the Java Runtime (JRE) ran into
address space limitations due to a 2G/2G split on embedded systems.
Reverting to a 3G/1G split fixed the problems.

Thanks,
//richard

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[René Herman]

> In the past I saw that programs such as the Java Runtime (JRE) ran
> into address space limitations due to a 2G/2G split on embedded
> systems. Reverting to a 3G/1G split fixed the problems.
Believe you guys are talking specifically ARM so FWIW, but I remember 
for x86 that at least initially Wine and things such as VMware were 
affected by the more creative PAGE_OFFSET choices.

Both will have been as a matter of plain bugs and are supposedly long 
fixed (and I in fact believe I recall such fixing for VMware). Never had 
or as far as I recall heard of other issues back then.

Rene.

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Andreas Larsson]

On 2025-09-09 23:23, Arnd Bergmann wrote:
> High memory is one of the least popular features of the Linux kernel.
> Added in 1999 for linux-2.3.16 to support large x86 machines, there
> are very few systems that still need it. I talked about about this
> recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
> and there were a few older discussions before[4][5][6].
> 
> While removing a feature that is actively used is clearly a regression
> and not normally done, I expect removing highmem is going to happen
> at some point anyway when there are few enough users, but the question
> is when that time will be.
> 
> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason. Some
> users obviously are alarmed about potentially losing this ability,
> so I hope to get a broad consensus on a specific timeline for how long
> we plan to support highmem in the page cache and to give every user
> sufficient time to migrate to a well-tested alternative setup if that
> is possible, or stay on a highmem-enabled LTS kernel for as long
> as necessary.

We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
used in LEON sparc32 configuration (using 36-bit physical addressing), a
removed CONFIG_HIGHMEM would be a considerable limitation, even after an
introduction of different CONFIG_VMSPLIT_* options for sparc32.

Regards,
Andreas

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Thu, Sep 11, 2025, at 07:38, Andreas Larsson wrote:
>
> We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
> used in LEON sparc32 configuration (using 36-bit physical addressing), a
> removed CONFIG_HIGHMEM would be a considerable limitation, even after an
> introduction of different CONFIG_VMSPLIT_* options for sparc32.

I agree that without highmem that chip is going to be unusable from Linux,
but I wonder if there is a chance to actually use it even with highmem,
for a combination of reasons:

- sparc32 has 36-bit addressing in the MMU, but Linux apparently never
  supported a 64-bit phys_addr_t here, which would be required.
  This is probably the easiest part and I assume you already have patches
  for it.

- As far as I can tell, the current lowmem area is 192MB, which would
  be ok(-ish) on a 512MB maxed-out SPARCstation, but for anything bigger
  you likely run out of lowmem long before being able to touch the
  all highmem pages. This obviously depends a lot on the workload.

- If you come up with patches to extend lowmem to 2GB at the expense
  of a lower TASK_SIZE, you're still  looking at a ration of 7:1 with
  14GB of highmem on the maxed-out configuration, so many workloads
  would still struggle to actually use that memory for page cache.

- If we remove HIGHPTE (as discussed in this thread) but keep HIGHMEM,
  you probably still lose on the 16GB configuration. On 4GB configurations,
  HIGHPTE is not really a requirement, but for workloads with many
  concurrent tasks using a lot of virtual address space, you would
  likely want to /add/ HIGHPTE support on sparc32 first.

When you say "used in LEON sparc32 configuration", does that mean
you can also run Linux in some other confuration like an rv64
kernel on a NOEL-V core on that chip?

Aside from the upcoming SoC and whatever happens to that, what is
the largest LEON Linux memory configuration that you know is used
in production today and still requires kernel updates beyond ~2029?

      Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Andreas Larsson]

On 2025-09-11 09:53, Arnd Bergmann wrote:
> On Thu, Sep 11, 2025, at 07:38, Andreas Larsson wrote:
>>
>> We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
>> used in LEON sparc32 configuration (using 36-bit physical addressing), a
>> removed CONFIG_HIGHMEM would be a considerable limitation, even after an
>> introduction of different CONFIG_VMSPLIT_* options for sparc32.
> 
> I agree that without highmem that chip is going to be unusable from Linux,
> but I wonder if there is a chance to actually use it even with highmem,
> for a combination of reasons:

I would definitely not call it unusable in LEON sparc32 mode with
HIGHMEM gone, but it would of course be seriously hampered memory wise
without HIGHMEM support compared to with HIGHMEM. In NOEL-V 64-bit
RISC-V mode it will of course not be affected by these matters.


> - sparc32 has 36-bit addressing in the MMU, but Linux apparently never
>   supported a 64-bit phys_addr_t here, which would be required.
>   This is probably the easiest part and I assume you already have patches
>   for it.
> 
> - As far as I can tell, the current lowmem area is 192MB, which would
>   be ok(-ish) on a 512MB maxed-out SPARCstation, but for anything bigger
>   you likely run out of lowmem long before being able to touch the
>   all highmem pages. This obviously depends a lot on the workload.
> 
> - If you come up with patches to extend lowmem to 2GB at the expense
>   of a lower TASK_SIZE, you're still  looking at a ration of 7:1 with
>   14GB of highmem on the maxed-out configuration, so many workloads
>   would still struggle to actually use that memory for page cache.

Yes, we already have patches for 36-bit addressing with 64-bit
phys_addr_t. Patches for CONFIG_VMSPLIT_* are under development.

Even with 192 MiB lowmem we have being using up to 4 GiB without running
into problems. Could you elaborate on why you think lowmem would run out
before 14 GiB highmem in a VMSPLIT_3G or VMSPLIT_2G configuration?

And even if 14 GiB highmem would be hard to get full usage out of, for a
board with 8 GiB memory (or a configuration limiting 16 GiB down to only
use 8 GiB or somewhere in between) the difference between getting to use
2 GiB and 8 GiB is quite hefty.

 
> - If we remove HIGHPTE (as discussed in this thread) but keep HIGHMEM,
>   you probably still lose on the 16GB configuration. On 4GB configurations,
>   HIGHPTE is not really a requirement, but for workloads with many
>   concurrent tasks using a lot of virtual address space, you would
>   likely want to /add/ HIGHPTE support on sparc32 first.

That is an interesting point. Regardless of workloads though, it still
would be a huge difference between having or not having HIGHMEM, with or
without HIGHPTE.


> When you say "used in LEON sparc32 configuration", does that mean
> you can also run Linux in some other confuration like an rv64
> kernel on a NOEL-V core on that chip?

Yes, boot strapping will select between sparc32 LEON and rv64 NOEL-V.


> Aside from the upcoming SoC and whatever happens to that, what is
> the largest LEON Linux memory configuration that you know is used
> in production today and still requires kernel updates beyond ~2029?

The maximum I know of for systems currently in production has the
capacity to have up to 2 GiB memory.


Cheers,
Andreas

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[H. Peter Anvin]

On September 12, 2025 2:32:04 AM PDT, Andreas Larsson <andreas@gaisler.com> wrote:
>On 2025-09-11 09:53, Arnd Bergmann wrote:
>> On Thu, Sep 11, 2025, at 07:38, Andreas Larsson wrote:
>>>
>>> We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
>>> used in LEON sparc32 configuration (using 36-bit physical addressing), a
>>> removed CONFIG_HIGHMEM would be a considerable limitation, even after an
>>> introduction of different CONFIG_VMSPLIT_* options for sparc32.
>> 
>> I agree that without highmem that chip is going to be unusable from Linux,
>> but I wonder if there is a chance to actually use it even with highmem,
>> for a combination of reasons:
>
>I would definitely not call it unusable in LEON sparc32 mode with
>HIGHMEM gone, but it would of course be seriously hampered memory wise
>without HIGHMEM support compared to with HIGHMEM. In NOEL-V 64-bit
>RISC-V mode it will of course not be affected by these matters.
>
>
>> - sparc32 has 36-bit addressing in the MMU, but Linux apparently never
>>   supported a 64-bit phys_addr_t here, which would be required.
>>   This is probably the easiest part and I assume you already have patches
>>   for it.
>> 
>> - As far as I can tell, the current lowmem area is 192MB, which would
>>   be ok(-ish) on a 512MB maxed-out SPARCstation, but for anything bigger
>>   you likely run out of lowmem long before being able to touch the
>>   all highmem pages. This obviously depends a lot on the workload.
>> 
>> - If you come up with patches to extend lowmem to 2GB at the expense
>>   of a lower TASK_SIZE, you're still  looking at a ration of 7:1 with
>>   14GB of highmem on the maxed-out configuration, so many workloads
>>   would still struggle to actually use that memory for page cache.
>
>Yes, we already have patches for 36-bit addressing with 64-bit
>phys_addr_t. Patches for CONFIG_VMSPLIT_* are under development.
>
>Even with 192 MiB lowmem we have being using up to 4 GiB without running
>into problems. Could you elaborate on why you think lowmem would run out
>before 14 GiB highmem in a VMSPLIT_3G or VMSPLIT_2G configuration?
>
>And even if 14 GiB highmem would be hard to get full usage out of, for a
>board with 8 GiB memory (or a configuration limiting 16 GiB down to only
>use 8 GiB or somewhere in between) the difference between getting to use
>2 GiB and 8 GiB is quite hefty.
>
> 
>> - If we remove HIGHPTE (as discussed in this thread) but keep HIGHMEM,
>>   you probably still lose on the 16GB configuration. On 4GB configurations,
>>   HIGHPTE is not really a requirement, but for workloads with many
>>   concurrent tasks using a lot of virtual address space, you would
>>   likely want to /add/ HIGHPTE support on sparc32 first.
>
>That is an interesting point. Regardless of workloads though, it still
>would be a huge difference between having or not having HIGHMEM, with or
>without HIGHPTE.
>
>
>> When you say "used in LEON sparc32 configuration", does that mean
>> you can also run Linux in some other confuration like an rv64
>> kernel on a NOEL-V core on that chip?
>
>Yes, boot strapping will select between sparc32 LEON and rv64 NOEL-V.
>
>
>> Aside from the upcoming SoC and whatever happens to that, what is
>> the largest LEON Linux memory configuration that you know is used
>> in production today and still requires kernel updates beyond ~2029?
>
>The maximum I know of for systems currently in production has the
>capacity to have up to 2 GiB memory.
>
>
>Cheers,
>Andreas
>
>

SPARC32 has a 4:4 address space.  You still use HIGHMEM?!

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[H. Peter Anvin]

On September 10, 2025 10:38:15 PM PDT, Andreas Larsson <andreas@gaisler.com> wrote:
>On 2025-09-09 23:23, Arnd Bergmann wrote:
>> High memory is one of the least popular features of the Linux kernel.
>> Added in 1999 for linux-2.3.16 to support large x86 machines, there
>> are very few systems that still need it. I talked about about this
>> recently at the Embedded Linux Conference on 32-bit systems [1][2][3]
>> and there were a few older discussions before[4][5][6].
>> 
>> While removing a feature that is actively used is clearly a regression
>> and not normally done, I expect removing highmem is going to happen
>> at some point anyway when there are few enough users, but the question
>> is when that time will be.
>> 
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason. Some
>> users obviously are alarmed about potentially losing this ability,
>> so I hope to get a broad consensus on a specific timeline for how long
>> we plan to support highmem in the page cache and to give every user
>> sufficient time to migrate to a well-tested alternative setup if that
>> is possible, or stay on a highmem-enabled LTS kernel for as long
>> as necessary.
>
>We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
>used in LEON sparc32 configuration (using 36-bit physical addressing), a
>removed CONFIG_HIGHMEM would be a considerable limitation, even after an
>introduction of different CONFIG_VMSPLIT_* options for sparc32.
>
>Regards,
>Andreas
>
>

It really sounds like a self-inflicted problem... getting your customers switched over to the RV64 side is probably the best you can do for them.

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Fri, Sep 12, 2025, at 11:32, Andreas Larsson wrote:
> On 2025-09-11 09:53, Arnd Bergmann wrote:
>> On Thu, Sep 11, 2025, at 07:38, Andreas Larsson wrote:
>>>
>>> We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
>>> used in LEON sparc32 configuration (using 36-bit physical addressing), a
>>> removed CONFIG_HIGHMEM would be a considerable limitation, even after an
>>> introduction of different CONFIG_VMSPLIT_* options for sparc32.
>> 
>> I agree that without highmem that chip is going to be unusable from Linux,
>> but I wonder if there is a chance to actually use it even with highmem,
>> for a combination of reasons:
>
> I would definitely not call it unusable in LEON sparc32 mode with
> HIGHMEM gone, but it would of course be seriously hampered memory wise
> without HIGHMEM support compared to with HIGHMEM.

I meant specifically a configuration with 16GB of RAM would be
unusable.

>> - If you come up with patches to extend lowmem to 2GB at the expense
>>   of a lower TASK_SIZE, you're still  looking at a ration of 7:1 with
>>   14GB of highmem on the maxed-out configuration, so many workloads
>>   would still struggle to actually use that memory for page cache.
>
> Yes, we already have patches for 36-bit addressing with 64-bit
> phys_addr_t. Patches for CONFIG_VMSPLIT_* are under development.

Ok

> Even with 192 MiB lowmem we have being using up to 4 GiB without running
> into problems. Could you elaborate on why you think lowmem would run out
> before 14 GiB highmem in a VMSPLIT_3G or VMSPLIT_2G configuration?
>
> And even if 14 GiB highmem would be hard to get full usage out of, for a
> board with 8 GiB memory (or a configuration limiting 16 GiB down to only
> use 8 GiB or somewhere in between) the difference between getting to use
> 2 GiB and 8 GiB is quite hefty.

This is highly workload dependent, but usually what happens is that
one type of allocations fills up lowmem to the point where the
system runs out of memory. This could be any of:

- AFAICT the mem_map[] array uses 40 bytes per physical page on sparc64,
  so on 16GB, you need 160MB of lowmem for the mem_map[] alone.
- to actually access the memory from user space, you need several tasks
  that each map a portion of the physical memory. Each task requires
  at least page tables, task_struct, kernel stack, inodes, vma structures
  etc, all of which have to be in lowmem.
- anything you find in /proc/slabinfo comes from lowmem, and for any
  network or filesystem heavy workload, there are a lot of those

It's easy to construct an artifical testcase that maximises the
highmem usage, but much harder to change an existing workload to
use highmem without using more lowmem as well.

>> When you say "used in LEON sparc32 configuration", does that mean
>> you can also run Linux in some other confuration like an rv64
>> kernel on a NOEL-V core on that chip?
>
> Yes, boot strapping will select between sparc32 LEON and rv64 NOEL-V.

>> Aside from the upcoming SoC and whatever happens to that, what is
>> the largest LEON Linux memory configuration that you know is used
>> in production today and still requires kernel updates beyond ~2029?
>
> The maximum I know of for systems currently in production has the
> capacity to have up to 2 GiB memory.

Ok. The 2GB point is clearly the one that works well enough on
x86-32, arm32, powerpc32 and others, with VMSPLIT_3G+highmem
that gives you a 1:1 or 2:1 ratio of highmem to lowmem, and
a single process is able to use all the available memory in
its 3GB virtual space. Alternatively you can already use 2GB
on those architectures with VMSPLIT_2G_OPT to have everything
in lowmem, again depending on your workload.

Once you go to 4GB and beyond, you really want a 64-bit kernel.
CPU designers have added 36-bit addressing to all the major
32-bit architectures at some point, but it's been very rare
that this was actually used after 64-bit CPUs became available.

    Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Wed, Sep 10, 2025, at 22:33, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Dave Hansen" <dave@sr71.net>
>>> Even with a new memory split, which could utilize most of the
>>> available memory, I expect there to be issues with various
>>> applications and FPGA device drivers.

I also remember driver problems on older Marvell NAS systems, which
we never fully figured out, my best guess in retrospect is that these
had devices with DMA address restrictions, and if lowmem is small
enough it would always work, but any lowmem allocation above the
hardware DMA address limit would cause data corruption.

A similar restriction exists on Raspberry Pi, which can run
both 32-bit and 64-bit kernels. The workaround in this case is
a combination of:

- correctly representing the DMA limits in the devicetree, using
  the 'dma-ranges' property.
- enabling SWIOTLB (which is not enabled by default on 32-bit
  Arm without LPAE).
- Using GFP_DMA or dma_alloc_noncoherent() allocations for
  streaming buffers if possible, to avoid extra bounces

(documenting this here, in case someone tries out VMSPLIT_2G
and runs into a similar bug on other hardware, I expect there
may be a few more of these, though most hardware should be fine)

>> I'd be really curious what the _actual_ issues would be with a
>> non-standard split. There are a lot of "maybe" problems and solutions
>> here, but it's hard to move forward without known practical problems to
>> tackle.
>> 
>> Has anybody run into actual end user visible problems when using one of
>> weirdo PAGE_OFFSET configs?
>
> In the past I saw that programs such as the Java Runtime (JRE) ran into
> address space limitations due to a 2G/2G split on embedded systems.
> Reverting to a 3G/1G split fixed the problems.

Right, that makes sense, given the tricks they likely play on the
virtual address space. Are the 2GB devices you maintain using a JRE,
or was this on other embedded hardware? How common is Java still in
this type of workload?

Another type of software that I've seen mentioned struggling with
VMSPLIT_2G is web browsers, but I don't know if that is a similar
problem with a V8/spidermonkey JIT managing its own address space,
or more about general bloat exceeding 2GB of user addresses.

      Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Linus Walleij]

On Fri, Sep 12, 2025 at 12:31 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Sep 10, 2025, at 22:33, Richard Weinberger wrote:
> > ----- Ursprüngliche Mail -----
> >> Von: "Dave Hansen" <dave@sr71.net>
> >>> Even with a new memory split, which could utilize most of the
> >>> available memory, I expect there to be issues with various
> >>> applications and FPGA device drivers.
>
> I also remember driver problems on older Marvell NAS systems, which
> we never fully figured out, my best guess in retrospect is that these
> had devices with DMA address restrictions, and if lowmem is small
> enough it would always work, but any lowmem allocation above the
> hardware DMA address limit would cause data corruption.

This kind of mess is often also driver problems, in the Kirkwood MMC
driver there is some dated code traversing sglists iteratively
instead of using sg_miter() on !DMA which I think is not entirely
safe either.

I wanted to fix that driver but the hardware is in my NAS and
all the time someone is watching a movie from it :D

Yours,
Linus Walleij

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Matthew Wilcox]

On Fri, Sep 12, 2025 at 02:58:48AM -0700, H. Peter Anvin wrote:
> On September 10, 2025 10:38:15 PM PDT, Andreas Larsson <andreas@gaisler.com> wrote:
> >We have a upcoming SoC with support for up to 16 GiB of DRAM. When that is
> >used in LEON sparc32 configuration (using 36-bit physical addressing), a
> >removed CONFIG_HIGHMEM would be a considerable limitation, even after an
> >introduction of different CONFIG_VMSPLIT_* options for sparc32.
> 
> It really sounds like a self-inflicted problem... getting your customers switched over to the RV64 side is probably the best you can do for them.


"We only support configurations above 4GB when using the RV64 core".

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Nicolas Ferre]

Arnd,

On 09/09/2025 at 23:23, Arnd Bergmann wrote:
> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason.

We have 1GB of memory on our latest Cortex-A7 SAMA7D65 evaluation boards 
[1] (full production announced beg. 2025). The wide range of DDR types 
supported make some of these types interesting to use at such density.
Both our Cortex-A7 SoCs don't have IOMMU; core and DMAs can address the 
full range of the 32 bit address space, so we're quite 
standard/simplistic in this area. We use CMA with large chunks as our 
camera or display interfaces address "modern-ish" resolutions (~1080p).

We use CONFIG_HIGHMEM and activated it for simplicity, conformance to 
usual user-space workloads and planned to add it to our sama7_defconfig 
[2]. I understand that we might reconsider this "by default" choice and 
move to one of the solutions you highlighted in your message, lwn.net 
article or recent talk at ELC-E.

Of course we plan to maintain these boards and keep updating our kernel 
"offer" once a year for those associated SoCs (with maintaining 
upstream, as usual). As you said, being ARMv7, we're quite confident for 
now.

As you mentioned, we've recently released one ARMv5te arm926ejs-based 
soc: the SAM9x75 family. But we don't have the intention to use too big 
memory sizes on them, even if they do address large screens, with LVDS 
and MIPI or modern camera interfaces...

I don't have too much info about our customer's use cases as they are 
very, very diverse, but don't hesitate to reach out to me if you have 
questions about a particular combination of use.
Thanks for your regular update on these topics.

Best regards,
   Nicolas

[1]: for instance: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts#n29

[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/sama7_defconfig

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Fri, Sep 12, 2025, at 18:49, Nicolas Ferre wrote:
> Arnd,
>
> On 09/09/2025 at 23:23, Arnd Bergmann wrote:
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason.
>
> We have 1GB of memory on our latest Cortex-A7 SAMA7D65 evaluation boards 
> [1] (full production announced beg. 2025). The wide range of DDR types 
> supported make some of these types interesting to use at such density.
> Both our Cortex-A7 SoCs don't have IOMMU; core and DMAs can address the 
> full range of the 32 bit address space, so we're quite 
> standard/simplistic in this area. We use CMA with large chunks as our 
> camera or display interfaces address "modern-ish" resolutions (~1080p).
>
> We use CONFIG_HIGHMEM and activated it for simplicity, conformance to 
> usual user-space workloads and planned to add it to our sama7_defconfig 
> [2]. I understand that we might reconsider this "by default" choice and 
> move to one of the solutions you highlighted in your message, lwn.net 
> article or recent talk at ELC-E.

Hi Nicolas,

Thanks for your summary! I think with 1GB, you'll be mostly on the safe
side in general. I would definitely recommend using VMSPLIT_3G_OPT
as the default in the long run and turn off highmem on those.

My expectation is that VMSPLIT_3G_OPT may uncover application bugs, but
those should be fixed anyway, while using highmem is safer but makes
everything slightly worse through the added runtime overhead and
increased fragmentation risk. The 1GB case has caused additional bugs
because it has a very small highmem area on CONFIG_VMSPLIT_3G and
that can make it run out of highmem first. 

> Of course we plan to maintain these boards and keep updating our kernel 
> "offer" once a year for those associated SoCs (with maintaining 
> upstream, as usual). As you said, being ARMv7, we're quite confident for 
> now.
>
> As you mentioned, we've recently released one ARMv5te arm926ejs-based 
> soc: the SAM9x75 family. But we don't have the intention to use too big 
> memory sizes on them, even if they do address large screens, with LVDS 
> and MIPI or modern camera interfaces...
>
> I don't have too much info about our customer's use cases as they are 
> very, very diverse, but don't hesitate to reach out to me if you have 
> questions about a particular combination of use.
> Thanks for your regular update on these topics.

I'm curious about the AT91RM9200 part, which I think is the oldest 
SoC with Linux support that is still advertised as "in production".
I understand that Microchip hardly ever discontinues parts, and there is
clearly no need to stop supporting it as long as you maintain the SAM9
family, but I wonder how many users are still buying this part or
running the latest kernel on it. 

    Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Jason Gunthorpe]

On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:

> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason. 

On this topic of removing some parts of highmem, can we say goodbye to
kmap_high_get()? Only ARM uses it and only for
!cache_is_vipt_nonaliasing() systems.

Maybe if so then HASHED_PAGE_VIRTUAL can go too?

Jason

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason. 
>
> On this topic of removing some parts of highmem, can we say goodbye to
> kmap_high_get()? Only ARM uses it and only for
> !cache_is_vipt_nonaliasing() systems.

Good idea. I think we are almost there, just need to verify that
there is actually no impact for existing users. I already knew
that there is very little highmem usage on ARMv6 and earlier, but
I tried to recheck all platforms that might be affected:

* As you say (and contrary to what the code comments suggest),
  all ARMv7 and most ARMv6 systems have non-aliasing VIPT or
  PIPT caches, so kmap_high_get() does nothing, and we could
  just turn it off for those configurations.

* ARMv6 with aliasing VIPT caches exist but are fairly rare,
  and I think there are no ARMv6 machines left that actually
  use highmem. AST2500 is commonly used and has aliasing
  caches, but I only see machines with 512MB or less, and
  its aspeed_v5_defconfig enables CONFIG_SMP (for AST2600).
  OMAP2 and realview are in the same category but less
  important. imx3, s3c64xx and bcm2835 are non-aliasing
  (and don't have highmem either).

* VIVT caches are used on all ARMv5 and earlier, so removing
  kmap_high_get() would effectively break highmem these.
  Most ARMv5 use very small amounts of memory (<256M) in
  a single physical address range, so they are unaffected,
  we just have to go through the ones that are left.

* Intel IOP (armv5 xscale) certainly had highmem but was
  removed a while ago.

* Marvell mv78xx0 and kirkwood (armv5 pj1) were fairly
  powerful in 2008 and could support at least 1GB of RAM,
  but I only found one machine (OpenBlocks A7) that does
  this. It's unclear if anyone is still updating kernels
  on this machine, but they could /probably/ use
  VMSPLIT_3G_OPT if they do.

* Microchip SAM9x7 is the newest ARMv5 chip, clearly does
  get kernel updates, and the only one I can think of with
  DDR3 support, but seems to be limited to 256MB total memory.

* The Gemini (ARMv4) platform enabled highmem as part of
  commit c12d7e9fe9af ("ARM: defconfig: Update Gemini defconfig"),
  but I don't see why, as the machine cited there only has
  128MB of RAM in a contiguous chunk.

* A few ARMv4/v5 machines (omap1, davinci, ep93xx, clps71xx,
  sa1100, riscpc) used to select CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
  or SPARSEMEM, which would indicate that they might need
  highmem even for <1GB configurations if their memory banks are
  far apart in physical memory. I checked those and as far
  as I can tell, they are always within 768MB or less.

     Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Andrew Lunn]

> * Marvell mv78xx0 and kirkwood (armv5 pj1) were fairly
>   powerful in 2008 and could support at least 1GB of RAM,
>   but I only found one machine (OpenBlocks A7) that does
>   this. It's unclear if anyone is still updating kernels
>   on this machine, but they could /probably/ use
>   VMSPLIT_3G_OPT if they do.

If i remember correctly, there was a design issue with the OpenBlocks
A7, and it would not run with its full amount of memory. To get a
stable system you had to limit the RAM. I don't remember if that was
just with the NULL series, and it was fixed for mass production
devices, or they are all broken.

I doubt there are any mv78xx0 machines left, why where never very
popular, but there are still Kirkwood NAS boxes around. I keep mine up
to date, put an LTS kernel on it once a year, update to the latest
debian sid.

	Andrew

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Thu, Sep 18, 2025, at 15:34, Andrew Lunn wrote:
>> * Marvell mv78xx0 and kirkwood (armv5 pj1) were fairly
>>   powerful in 2008 and could support at least 1GB of RAM,
>>   but I only found one machine (OpenBlocks A7) that does
>>   this. It's unclear if anyone is still updating kernels
>>   on this machine, but they could /probably/ use
>>   VMSPLIT_3G_OPT if they do.
>
> If i remember correctly, there was a design issue with the OpenBlocks
> A7, and it would not run with its full amount of memory. To get a
> stable system you had to limit the RAM. I don't remember if that was
> just with the NULL series, and it was fixed for mass production
> devices, or they are all broken.

It's possible that the bug is in the exact bit of code that
Jason was suggesting to have removed, if this was the last
ARMv5 machine that actually tried to use highmem.

> I doubt there are any mv78xx0 machines left, why where never very
> popular, but there are still Kirkwood NAS boxes around.

https://github.com/1000001101000/Debian_on_Buffalo does support
some variations of the Terastation Duo, and they were planning
to do a DT conversion at some point, but I think there is not
much hope of that ever happening now that Debian armel has had
its last release, and I expect we can drop the entire platform
soon.

The reference system for mv78xx0 of course was the platform
that Nico used for implementing highmem on, with a full 2GB
of RAM. I think in the end this was around the same time
as dove and then armada xp.

> I keep mine up to date, put an LTS kernel on it once a year,
> update to the latest debian sid.

Do you know of any kirkwood machines beside the OpenBlocks A7
that have more than 512MB of RAM?

    Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Andrew Lunn]

> Do you know of any kirkwood machines beside the OpenBlocks A7
> that have more than 512MB of RAM?

No.

	Andrew

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Geert Uytterhoeven]

Hi Arnd,

On Thu, 18 Sept 2025 at 15:13, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
> > On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
> >
> >> I'm still collecting information about which of the remaining highmem
> >> users plan to keep updating their kernels and for what reason.
> >
> > On this topic of removing some parts of highmem, can we say goodbye to
> > kmap_high_get()? Only ARM uses it and only for
> > !cache_is_vipt_nonaliasing() systems.
>
> Good idea. I think we are almost there, just need to verify that
> there is actually no impact for existing users. I already knew
> that there is very little highmem usage on ARMv6 and earlier, but
> I tried to recheck all platforms that might be affected:

> * Microchip SAM9x7 is the newest ARMv5 chip, clearly does
>   get kernel updates, and the only one I can think of with
>   DDR3 support, but seems to be limited to 256MB total memory.

Are they limited to DDR3?

IIRC, someone (you? ;-) told me at ELCE that Microchip keeps on spinning
new variants of old SoCs, to accommodate the changing DDR landscape
and market.  So perhaps they also accept larger RAM sizes?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Nicolas Ferre]

On 18/09/2025 at 15:12, Arnd Bergmann wrote:
> * Microchip SAM9x7 is the newest ARMv5 chip, clearly does
>    get kernel updates, and the only one I can think of with
>    DDR3 support, but seems to be limited to 256MB total memory.

It is indeed.
No difficulty on this part of the product line ;-)

Best regards,
   Nicolas

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Fri, Sep 19, 2025, at 09:17, Geert Uytterhoeven wrote:
> On Thu, 18 Sept 2025 at 15:13, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
>> > On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> * Microchip SAM9x7 is the newest ARMv5 chip, clearly does
>>   get kernel updates, and the only one I can think of with
>>   DDR3 support, but seems to be limited to 256MB total memory.
>
> Are they limited to DDR3?
>
> IIRC, someone (you? ;-) told me at ELCE that Microchip keeps on spinning
> new variants of old SoCs, to accommodate the changing DDR landscape
> and market.  So perhaps they also accept larger RAM sizes?

Yes, that was me. The previous SAM9x60 was released in 2020
and I think that one was an upgrade to a smaller process node,
raising the clock frequency to 600MHz and adding more modern
peripherals, but I see now that this used the same SDRAM/LPDDR/DDR2
memory controller as previous chips, with a limit of 128MB
total DRAM.

SAM9X7 in 2023 added DDR3 mode with up to 256MB according to
the datasheet, no idea why they chose not to support more,
since a 32-bit wide DDR3 bus should allow up to 1GB with two
256Mbit x16 chips that are widely available, or even more using
expensive 512Mbit x16 or 1Gbit x8 chips.

       Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Jason Gunthorpe]

On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:

> SAM9X7 in 2023 added DDR3 mode with up to 256MB according to
> the datasheet, no idea why they chose not to support more,

Quite possible the internal SOC wiring only has 28 address lines. :)

I am right it sounds like we can drop vivt cache support with highmem?
vivt is alot easier to understand if kmap isn't running around
creating virtual addresses aliases!

Jason

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Nicolas Ferre]

Hi Geert,

On 19/09/2025 at 09:17, Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Thu, 18 Sept 2025 at 15:13, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
>>> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>>>
>>>> I'm still collecting information about which of the remaining highmem
>>>> users plan to keep updating their kernels and for what reason.
>>>
>>> On this topic of removing some parts of highmem, can we say goodbye to
>>> kmap_high_get()? Only ARM uses it and only for
>>> !cache_is_vipt_nonaliasing() systems.
>>
>> Good idea. I think we are almost there, just need to verify that
>> there is actually no impact for existing users. I already knew
>> that there is very little highmem usage on ARMv6 and earlier, but
>> I tried to recheck all platforms that might be affected:
> 
>> * Microchip SAM9x7 is the newest ARMv5 chip, clearly does
>>    get kernel updates, and the only one I can think of with
>>    DDR3 support, but seems to be limited to 256MB total memory.
> 
> Are they limited to DDR3?

For sam9x75:
- DDR2
- DDR3  (DLL Off/On mode)
- DDR3L (DLL Off/On mode)

For (older) sam9x60:
- LPDDR1
- DDR2
- SDRAM & Mobile SDRAM
> IIRC, someone (you? ;-) told me at ELCE that Microchip keeps on spinning
> new variants of old SoCs, to accommodate the changing DDR landscape
> and market.  So perhaps they also accept larger RAM sizes?
No, in fact we address 256 M Bytes max on sam9x60 and sam9x75 as well.

Regards,
   Nicolas

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Fri, Sep 19, 2025, at 16:34, Jason Gunthorpe wrote:
> On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:
>
>> SAM9X7 in 2023 added DDR3 mode with up to 256MB according to
>> the datasheet, no idea why they chose not to support more,
>
> Quite possible the internal SOC wiring only has 28 address lines. :)
>
> I am right it sounds like we can drop vivt cache support with highmem?
> vivt is alot easier to understand if kmap isn't running around
> creating virtual addresses aliases!

I think so, yes. I've prototyped a patch for it to add a dependency
on !VIVT and the drop the code paths that are clearly no longer
needed without it. This obviously needs proper testing, but the
diffstat is promising:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f14bac913d50..0a31cfaf3818 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1214,6 +1214,7 @@ config ARCH_SPARSEMEM_ENABLE
 config HIGHMEM
        bool "High Memory Support"
        depends on MMU
+       depends on !CPU_CACHE_VIVT
        select KMAP_LOCAL
        select KMAP_LOCAL_NON_LINEAR_PTE_ARRAY
        help
 arch/arm/Kconfig                    |  1 +
 arch/arm/configs/gemini_defconfig   |  1 -
 arch/arm/configs/multi_v5_defconfig |  1 -
 arch/arm/configs/mvebu_v5_defconfig |  1 -
 arch/arm/include/asm/highmem.h      | 56 +-----------------------
 arch/arm/mm/cache-feroceon-l2.c     | 31 +------------
 arch/arm/mm/cache-xsc3l2.c          | 47 +++-----------------
 arch/arm/mm/dma-mapping.c           | 14 ++----
 arch/arm/mm/flush.c                 | 19 ++------
 mm/highmem.c                        | 86 +++++--------------------------------
 10 files changed, 27 insertions(+), 230 deletions(-)

I did get an email from Nicolas Schichan (added to Cc here),
and he is still supporting a widely deployed Kirkwood based
platform that uses 1GB RAM configurations. He should get
a chance to test that with CONFIG_VMSPLIT_3G_OPT, but I
would expect that to continue working, possibly with minor
bugfixes.

For the timeline, the coming merge window is for an LTS
release, so if we remove VIVT highmem support in 6.19,
any remaining users we missed at least still be able to
use 6.18 for a couple of years and get security updates.

      Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Nicolas Schichan]

> On Fri, Sep 19, 2025, at 16:34, Jason Gunthorpe wrote:
> > On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:
[...]
> > I am right it sounds like we can drop vivt cache support with highmem?
> > vivt is alot easier to understand if kmap isn't running around
> > creating virtual addresses aliases!
>
> I think so, yes. I've prototyped a patch for it to add a dependency
> on !VIVT and the drop the code paths that are clearly no longer
> needed without it. This obviously needs proper testing, but the
> diffstat is promising:
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f14bac913d50..0a31cfaf3818 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1214,6 +1214,7 @@ config ARCH_SPARSEMEM_ENABLE
>  config HIGHMEM
>         bool "High Memory Support"
>         depends on MMU
> +       depends on !CPU_CACHE_VIVT
>         select KMAP_LOCAL
>         select KMAP_LOCAL_NON_LINEAR_PTE_ARRAY
>         help
>  arch/arm/Kconfig                    |  1 +
>  arch/arm/configs/gemini_defconfig   |  1 -
>  arch/arm/configs/multi_v5_defconfig |  1 -
>  arch/arm/configs/mvebu_v5_defconfig |  1 -
>  arch/arm/include/asm/highmem.h      | 56 +-----------------------
>  arch/arm/mm/cache-feroceon-l2.c     | 31 +------------
>  arch/arm/mm/cache-xsc3l2.c          | 47 +++-----------------
>  arch/arm/mm/dma-mapping.c           | 14 ++----
>  arch/arm/mm/flush.c                 | 19 ++------
>  mm/highmem.c                        | 86 +++++--------------------------------
>  10 files changed, 27 insertions(+), 230 deletions(-)
>
> I did get an email from Nicolas Schichan (added to Cc here),
> and he is still supporting a widely deployed Kirkwood based
> platform that uses 1GB RAM configurations. He should get
> a chance to test that with CONFIG_VMSPLIT_3G_OPT, but I
> would expect that to continue working, possibly with minor
> bugfixes.

Hello Arnd,

We don't use HIGMEM on our Kirkwood platform, we are happy using a
2G/2G WMSPLIT. We don't need a lot of virtual address space for
userland, and with the 2G split we don't waste physical memory.

I'm happy to test your patch serie with VMSPLIT_3G_OPT and see if it
still boots with it once you send it.

Regards,

-- 
Nicolas Schichan

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Arnd Bergmann]

On Mon, Sep 22, 2025, at 19:05, Nicolas Schichan wrote:
>> On Fri, Sep 19, 2025, at 16:34, Jason Gunthorpe wrote:
>> > On Fri, Sep 19, 2025 at 04:22:20PM +0200, Arnd Bergmann wrote:
>>
>> I did get an email from Nicolas Schichan (added to Cc here),
>> and he is still supporting a widely deployed Kirkwood based
>> platform that uses 1GB RAM configurations. He should get
>> a chance to test that with CONFIG_VMSPLIT_3G_OPT, but I
>> would expect that to continue working, possibly with minor
>> bugfixes.
>
> We don't use HIGMEM on our Kirkwood platform, we are happy using a
> 2G/2G WMSPLIT. We don't need a lot of virtual address space for
> userland, and with the 2G split we don't waste physical memory.

Ok, good.

> I'm happy to test your patch serie with VMSPLIT_3G_OPT and see if it
> still boots with it once you send it.

The patches I did for turning off HIGHMEM on ARMv5 won't have
any effect if you are already running without highmem, so I
don't think we need to wait for your tests specifically.
Any testing would be useful of course just to check that
everything still works.

Jason, I think we can go ahead with your suggestion. I can
post my patches for review once I've done some testing on
them.

     Arnd

Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Arnd Bergmann" <arnd@arndb.de>
>>> Has anybody run into actual end user visible problems when using one of
>>> weirdo PAGE_OFFSET configs?
>>
>> In the past I saw that programs such as the Java Runtime (JRE) ran into
>> address space limitations due to a 2G/2G split on embedded systems.
>> Reverting to a 3G/1G split fixed the problems.
> 
> Right, that makes sense, given the tricks they likely play on the
> virtual address space. Are the 2GB devices you maintain using a JRE,
> or was this on other embedded hardware? How common is Java still in
> this type of workload?

Sorry for the late reply, I was on vacation.

No, the devices with the JRE issues are from a different customer.
Since I work as a consultant lots of strange issues get thrown my way

I wouldn't say Java is super common but I still see it from time to time.
 
Thanks,
//richard