3 ms·

If a CPU's caches are physically tagged and both process's page tables share the same backing physical page then the CPU will let the cache contents be used by

by zeusk 3y ago

If a CPU's caches are physically tagged and both process's page tables share the same backing physical page then the CPU will let the cache contents be used by either process as long as the OS doesn't explicitly flush/invalidate cache on context switch.

twoodfin 3y ago
The major cost of two processes coordinating shared data over two threads is TLB invalidation on a context switch. I assume this is what the author meant by “page table contention” as a bottleneck: Without TLB invalidation there would be no need for either process/thread to ever touch page tables in a scenario like this.
- zeusk 3y ago
  It's unrelated to TLB; page table contention is related to associative caches where you can have two distinct addresses map to the same cache set and cause false cache miss or exhaust the cache set and cause repeated fill from memory. TLB has to be flushed for process context switch on x86 regardless of Windows/Linux - but modern systems typically allow it to be selectively flushed (the system can elect to not flush tlb for the shared mappings that exist in both processes). TLB miss vs Cache miss are an order of magnitude apart, and multiple orders if the corresponding pte itself is resident in dcache.
  - twoodfin 3y ago
    TLB has to be flushed for process context switch on x86 regardless of Windows/Linux - but modern systems typically allow it to be selectively flushed (the system can elect to not flush tlb for the shared mappings that exist in both processes). What’s the mechanism for this? AFAIK one of the main motivations for the recent heated discussions on PostgreSQL adopting a threaded model would be eliminating TLB flushes in high-context-switch environments. Can Linux already preserve their (massive) shared mappings?
    - zeusk 3y ago
      ASID (Address Space ID) or as Intel calls it PCID (Process Context ID). The OS juggles these based on what processes are resident on CPU and the various active mappings then uses INVPCID[0] during a context switch. [0]: https://www.felixcloutier.com/x86/invpcid https://www.felixcloutier.com/x86/invpcid

by zeusk 3y ago

twoodfin 3y ago

The major cost of two processes coordinating shared data over two threads is TLB invalidation on a context switch. I assume this is what the author meant by “page table contention” as a bottleneck: Without TLB invalidation there would be no need for either process/thread to ever touch page tables in a scenario like this.

zeusk 3y ago
It's unrelated to TLB; page table contention is related to associative caches where you can have two distinct addresses map to the same cache set and cause false cache miss or exhaust the cache set and cause repeated fill from memory. TLB has to be flushed for process context switch on x86 regardless of Windows/Linux - but modern systems typically allow it to be selectively flushed (the system can elect to not flush tlb for the shared mappings that exist in both processes). TLB miss vs Cache miss are an order of magnitude apart, and multiple orders if the corresponding pte itself is resident in dcache.
- twoodfin 3y ago
  TLB has to be flushed for process context switch on x86 regardless of Windows/Linux - but modern systems typically allow it to be selectively flushed (the system can elect to not flush tlb for the shared mappings that exist in both processes). What’s the mechanism for this? AFAIK one of the main motivations for the recent heated discussions on PostgreSQL adopting a threaded model would be eliminating TLB flushes in high-context-switch environments. Can Linux already preserve their (massive) shared mappings?
  - zeusk 3y ago
    ASID (Address Space ID) or as Intel calls it PCID (Process Context ID). The OS juggles these based on what processes are resident on CPU and the various active mappings then uses INVPCID[0] during a context switch. [0]: https://www.felixcloutier.com/x86/invpcid https://www.felixcloutier.com/x86/invpcid