3 ms·

> This implementation is hardcoded to use 4GB virtual address for each vector, so you can have billions of these per process. The actual virtual address space

by gary_0 5y ago

> This implementation is hardcoded to use 4GB virtual address for each vector, so you can have billions of these per process. The actual virtual address space on current x86-64 processors is only 48 bits[0], so unless I am mistaken, you can only create thousands (around 2^16), not billions. [0] https://en.wikipedia.org/wiki/X86-64#Architectural_features https://en.wikipedia.org/wiki/X86-64#Architectural_features

_4r6j 5y ago
good catch will update
moonchild 5y ago
Moreover, the kernel generally takes the entire top half, so you actually only get 47 bits.
- gary_0 5y ago
  You also have to account for any shared objects that might get mapped in, the executable data, the stack, and the heap. AFAIK, usually only the low 32 address bits are used for all that, leaving us with 46 bits.
  - moonchild 5y ago
    Going from 47 bits to 46 bits would mean you've spent half your address space on something. 2^32 is much less than half of 2^47; you still have the _vast majority_ of a 47-bit address space.
    - gary_0 5y ago
      Ah, right. I can't math.
monocasa 5y ago
Since Ice Lake, a 57bit virtual address space has been allowed, but the core piece of your comment absolutely still applies.
- vardump 5y ago
  I wonder how much performance hit you get by enabling 57-bit virtual address space. One could imagine this could hurt very random access patterns due to extra layer of translation.
  - monocasa 5y ago
    Ostensibly your working set should be in your TLBs either way. If you're thrashing your TLB and causing page table walks regularly, 5 versus 6 memory accesses per fetch is rough regardless. If that's showing up in your profiler traces you should start looking at techniques like huge pages to better fit within your TLBs. You can see this in how, at worse case, a hardware virtualized page table walk can take 20 memory accesses by my count if it completes without trapping, Host addresses will by definition all reference the same PML4, so that'll be cached, but everything else could have to go all the way out to DRAM. In practice the overhead of that is typically in the low single digit percentage range.
    - monocasa 5y ago
      Blergh, I thought about it wrong, it's worse than 20. Obviously the whole PML4 isn't guaranteed to be cached.
deleted 5y ago
[deleted]

by gary_0 5y ago

_4r6j 5y ago

good catch will update

moonchild 5y ago

Moreover, the kernel generally takes the entire top half, so you actually only get 47 bits.

gary_0 5y ago
You also have to account for any shared objects that might get mapped in, the executable data, the stack, and the heap. AFAIK, usually only the low 32 address bits are used for all that, leaving us with 46 bits.
- moonchild 5y ago
  Going from 47 bits to 46 bits would mean you've spent half your address space on something. 2^32 is much less than half of 2^47; you still have the _vast majority_ of a 47-bit address space.
  - gary_0 5y ago
    Ah, right. I can't math.

monocasa 5y ago

Since Ice Lake, a 57bit virtual address space has been allowed, but the core piece of your comment absolutely still applies.

vardump 5y ago
I wonder how much performance hit you get by enabling 57-bit virtual address space. One could imagine this could hurt very random access patterns due to extra layer of translation.
- monocasa 5y ago
  Ostensibly your working set should be in your TLBs either way. If you're thrashing your TLB and causing page table walks regularly, 5 versus 6 memory accesses per fetch is rough regardless. If that's showing up in your profiler traces you should start looking at techniques like huge pages to better fit within your TLBs. You can see this in how, at worse case, a hardware virtualized page table walk can take 20 memory accesses by my count if it completes without trapping, Host addresses will by definition all reference the same PML4, so that'll be cached, but everything else could have to go all the way out to DRAM. In practice the overhead of that is typically in the low single digit percentage range.
  - monocasa 5y ago
    Blergh, I thought about it wrong, it's worse than 20. Obviously the whole PML4 isn't guaranteed to be cached.

deleted 5y ago

[deleted]