[HN Gopher] Understanding x86_64 Paging
___________________________________________________________________
Understanding x86_64 Paging
Author : signa11
Score : 86 points
Date : 2024-01-16 16:44 UTC (6 hours ago)
(HTM) web link (zolutal.github.io)
(TXT) w3m dump (zolutal.github.io)
| LAC-Tech wrote:
| Very cool. I've actually been trying to learn about this area
| recently. I know this was aside from the main thrust of the
| article, but this but made me think:
|
| _Page Cache Disabled (PCD) - pages descendant of this PGD entry
| should not enter the CPU's cache hierarchy, sometimes also called
| the 'Uncacheable' (UC) bit._
|
| I guess this is some optimisation where it's decided the page
| isn't worth taking up valuble CPU cache state. And now I'm
| wondering what this algorithm is that decides it..
| mark_undoio wrote:
| My guess is that this is useful when interacting with memory-
| mapped IO devices - individual accesses can have meaning at the
| device level, so you don't want the caches getting in the way
| (and e.g. removing / combining accesses or providing stale
| data).
| kimixa wrote:
| Also useful for memory you know you won't be touching
| multiple times and just thrash the cache.
|
| For example GPU drivers and texture copying - even on
| integrated GPUs that have cache coherency with the CPU (so
| don't "need" to manually flush it), there's no point filling
| the CPU cache with data you're only touching once with
| effectively a memcpy() on the CPU, you'll just evict more
| useful data you'll probably need to readback after anyway.
| loeg wrote:
| UC writes are very inefficient/slow. They are synchronous
| and not batched into cache lines. Oldschool GPUs used a UC-
| adjacent mode called WC (write combine) which was almost
| identical to UC just with adjacent-writes batched into full
| cache line writes. I think newer GPUs have dedicated DMA
| engines for copying to GPU memory that isn't mapped into
| the host address space but I'm not really familiar with
| these drivers.
|
| For anything that isn't MMIO, you would prefer using
| ordinary WB caching and non-temporal stores to avoid
| populating the cache instead of UC mode.
| PhilipRoman wrote:
| I don't think it's an optimization, for that you would
| typically use non-temporal instructions which avoid polluting
| cache with one-off accesses.
| ithkuil wrote:
| Is this useful for memory mapped IO?
| loeg wrote:
| UC is for MMIO.
| commandersaki wrote:
| This is great. I find the x86_64 paging to be very similar to
| RISC V which I was exposed to poring through xv6 code.
| phendrenad2 wrote:
| Easy on paper, hard to get right when trying to do this in C or
| Rust!
| drxzcl wrote:
| It diverges more from x86 than I would have expected!
| codeflo wrote:
| I'm not deeply familiar with either, though I have written a
| toy x86_64 bootloader once. There are more levels in x86_64
| (which makes sense to me that a larger address space would
| benefit from a sparser encoding). What else is significantly
| different?
| loeg wrote:
| x86 in some modes (PSE but not PAE) has 4MB superpages,
| whereas in PAE mode or in x86_64 they're 2MB (first level).
| That's the only one I remember off-hand.
___________________________________________________________________
(page generated 2024-01-16 23:00 UTC)