An end to high memory?

Posted Feb 28, 2020 10:04 UTC (Fri) by eru (subscriber, #2753)
In reply to: An end to high memory? by flussence
Parent article: An end to high memory?

What about a 4g/4g split? I seem to recall some distributions had this kind of feature to allow more memory for userspace.

An end to high memory?

Posted Feb 28, 2020 13:12 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (1 responses)

That wouldn't really be a "split" though - it would mean that all mappings have to be changed when entering and exiting the kernel, exactly what the split tried to prevent.

I wonder what the performance impact of just getting rid of the split in this manner would be. Isn't the performance advantage already rendered moot by KPTI?

An end to high memory?

Posted Feb 28, 2020 14:56 UTC (Fri) by arnd (subscriber, #8866) [Link]

I looked this up a few days ago, and the original patch set was from 2003 and only posted for review [https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450....] briefly then. It notably made it into the RHEL4 distro, but never into mainline kernels. Back then the main downside was that x86 CPUs of the time lacked a address space identifiers, so changing between user space and kernel always required flushing all TLBs, which has an enormous performance impact for system calls and page faults.

However, it does seem possible to use a 4G vmsplit on 32-bit ARM (probably also MIPS or others) ASIDs to avoid the TLB flush and keep the performance impact way down. On ARM with LPAE, we could e.g. use the split page tables to have the top 256MB (or another power-of-two size) reserved for vmalloc pages, modules, MMIO and the kernel image, while the lower 3.75GB are mapped to either user space or a large linear map. There is some extra overhead for copy_to_user() etc, but also extra isolation between user and kernel addresses that may provide security benefits.

It's also interesting that the original VMPLIT_4G_4G patches were not even intended to replace highmem, but to allow configurations with 32GB or 64GB of physical RAM that would otherwise fill a lot of the 896MB lowmem area with 'struct page' structures even before you start allocating inodes, dentries or page tables.