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-jackm...@google.com/
