linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [LSF/MM/BPF] Whither Highmem?
Date: Mon, 8 May 2023 00:20:42 +0100	[thread overview]
Message-ID: <ZFgySub+z210Rvsk@casper.infradead.org> (raw)


I see there's a couple of spots on the schedule open, so here's something
fun we could talk about.

Highmem was originally introduced to support PAE36 (up to 64GB) on x86
in the late 90s.  It's since been used to support a similar extension
on ARM (maybe other 32-bit architectures?)

Things have changed a bit since then.  There aren't a lot of systems
left which have more than 4GB of memory _and_ are incapable of running a
64-bit kernel.  We certainly don't see 64GB systems; maybe 8GB systems,
but 64-bit registers are cheap and if you're willing to solder 8GB of
RAM to the board, you're probably willing to splurge on a 64-bit ALU.

The objection might be raised that kmap_local() is cheap, and it is.
But when we have multi-page folios, particularly for filesystem metadata,
it gets awkward to use kmap because it only supports individual pages;
you can't kmap an entire folio.

So I'd like to explore removing support for keeping filesystem metadata
and page tables in highmem.  Anon memory and file memory should probably
remain supported in highmem.

Interested?


             reply	other threads:[~2023-05-07 23:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-07 23:20 Matthew Wilcox [this message]
2023-05-07 23:43 ` Kirill A. Shutemov
2023-05-08  0:23   ` Matthew Wilcox
2023-05-08  0:59     ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZFgySub+z210Rvsk@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox