3 ms·

It’s a big thread (by virtue of being a cool piece), so maybe someone said this already, but isn’t there kind of a middle ground where we let existing software

It’s a big thread (by virtue of being a cool piece), so maybe someone said this already, but isn’t there kind of a middle ground where we let existing software continue to run but acknowledge a changing hardware landscape by really cranking up (default) page sizes? Userland allocators already work pretty hard to hit in the TLB [1], but huge-page tuning and whatnot is, to your point, only hitting the sweet spot on modern gear via effort/luck. [1] https://engineering.fb.com/2011/01/03/core-data/scalable-memory-allocation-using-jemalloc/ https://engineering.fb.com/2011/01/03/core-data/scalable-mem...

phkamp 4y ago
I think that is a false dictomy. CHERI has shown that this kind of fundamental architectural improvements can happen with very little impact to running code.
- benreesman 4y ago
  Not to be contradictory, but I’m having a hell of a time getting a toolchain put together that can reproducibly target Linux on x86_64 without liking glibc or libstdc++ and easily accommodate open-source libraries, and it’s not for want of knowing how the individual pieces work. If you’re promoting computer architecture and OS research, have at it, needs doing. But that’s a different game to running software on the architectures, operating systems, and tool chains we have today.
Symmetry 4y ago
Channeling my inner Linux, defaulting to larger pages means a drastic loss in memory efficiency when mmaping lots of small files as happens when someone compiles the Linux kernel. If you've got a 2kb file and 4kb pages then half the memory you allocate when the file is paged in is wasted. For larger pages that goes way up.
- benreesman 4y ago
  Absolutely, but you also want a different scheduler for a low-latency server than you do for your desktop. One size almost never fits all, as I’m sure you’ll agree as someone who cares about compiling the kernel. With that said, the kernel is pretty good at reclaiming physical pages, so you’d most likely eat into the same disk cache you’re reading from in the scenario you’ve described.

phkamp 4y ago

I think that is a false dictomy. CHERI has shown that this kind of fundamental architectural improvements can happen with very little impact to running code.

benreesman 4y ago
Not to be contradictory, but I’m having a hell of a time getting a toolchain put together that can reproducibly target Linux on x86_64 without liking glibc or libstdc++ and easily accommodate open-source libraries, and it’s not for want of knowing how the individual pieces work. If you’re promoting computer architecture and OS research, have at it, needs doing. But that’s a different game to running software on the architectures, operating systems, and tool chains we have today.

Symmetry 4y ago

Channeling my inner Linux, defaulting to larger pages means a drastic loss in memory efficiency when mmaping lots of small files as happens when someone compiles the Linux kernel. If you've got a 2kb file and 4kb pages then half the memory you allocate when the file is paged in is wasted. For larger pages that goes way up.

benreesman 4y ago
Absolutely, but you also want a different scheduler for a low-latency server than you do for your desktop. One size almost never fits all, as I’m sure you’ll agree as someone who cares about compiling the kernel. With that said, the kernel is pretty good at reclaiming physical pages, so you’d most likely eat into the same disk cache you’re reading from in the scenario you’ve described.