tlb

问题 This scenario came into my head and it seems a bit basic but I'll ask. So there is a virtual index and physical tag in L1 but the set becomes full so it is evicted. How does the L1 controller get the full physical address from the virtual index and the physical tag in L1 so the line can be inserted into L2? I suppose it could search the TLB for the combination but that seems slow and also it may not be in the TLB at all. Perhaps the full physical address from the original TLB translation is

问题 I'm exploring leaf 0x02 of the cpuid instruction and came up with a few questions. There is a table in the documentation which describes what cpuid results mean for the TLB configuration. Here they are: case 1 56H TLB Data TLB0: 4 MByte pages, 4-way set associative, 16 entries [...] B4H TLB Data TLB1: 4 KByte pages, 4-way associative, 256 entries Does it mean that there are only 2 levels of TLB? How to query the number of levels of TLB cache in case some x86 vendor decides to provide 3 levels

问题 I am trying to implement tlb flush function. For flushing I use INVLPG instruction, but unfortunately it always cause segmentation fault. Could you help me with this issue? Here is the code: #include "stdlib.h" inline void tlb_flush_entry(int *m) { asm volatile ("invlpg %0"::"m"(*m):"memory"); } int main(int argc, char **argv) { int *memory = (int *)malloc(100); tlb_flush_entry(memory); } 回答1: The SIGSEGV happens because INVLPG is a privileged instruction and can only be called out of kernel

问题 I'm trying to measure memory access timings and need to reduce the noise produced by TLB hits and misses In order to clear a specific page out of the TLB I tried to use the INVLPG instruction, following those two examples: http://wiki.osdev.org/Paging and http://wiki.osdev.org/Inline_Assembly/Examples I wrote the following code: static inline void __native_flush_tlb_single(unsigned long addr) { asm volatile("invlpg (%0)" ::"r" (addr) : "memory"); } But the resulting binary throws an SIGSEGV

问题 I wonder if there is a common mechanism implemented in operating systems to minimize TLB flushes, by for instance grouping threads in the same process together in a "to be scheduled" list. I think this is an important factor when deciding between using processes against threads. If OS doesn't care whether the next thread is in the same process space or not, the so called advantage of threads "minimizing TLB flushes" might be overrated. Is that the case? Consider a system with hundreds of

问题 The wiki webpage(https://en.wikipedia.org/wiki/Sandy_Bridge) mentioned that Data TLB has 64, 32 and 4 entries respectively for 4KB, 2MB and 1GB pages. I found these numbers hard to understand. Sandy Bridge has a virtual address of 48 bits, which means for 4K page, there can be 2^36 pages, and for 2MB and 1GB pages, there should be 2^27 and 2^18 pages. If TLB has 64 entries for 4K page, the size of each entry should be no less than 6+36 = 42 bits. Why are there only 32 entries for 2M page,

问题 This question is related to this one: While "fork"ing a process, why does Linux kernel copy the content of kernel page table for every newly created process? I found that Linux kernel tries to avoid updating TTBR when switching between user land and kernel land by copying the content of swapper page table into every newly created page table in function pgd_alloc . Question is: What is the downside of updating ARM TTBR? 回答1: Updating the TTBR (translation table base register) Note1 with the

问题 Consider the following loop: .loop: add rsi, STRIDE mov eax, dword [rsi] dec ebp jg .loop where STRIDE is some non-negative integer and rsi contains a pointer to a buffer defined in the bss section. This loop is the only loop in the code. That is, it's not being initialized or touched before the loop. On Linux, all of the 4K virtual pages of the buffer will be mapped on-demand to the same physical page. I've ran this code for all possible strides in the range 0-8192. The measured number of

问题 for (int i = 0; i < 100000; ++i) { int *page = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); page[0] = 0; munmap(page, PAGE_SIZE); } I expect to get ~100000 dTLB-store-misses in userspace, one per each iteration (Also ~100000 page-faults and dTLB-load-misses for kernel). Running following command, the result is roughly 2x what I expect. I would appreciate if someone could clarify why this is the case: perf stat -e dTLB-store-misses:u ./test Performance

问题 I am observing the last few Intel microarchitectures (Nehalem/SB/IB and Haswell). I am trying to work out what happens (at a fairly simplified level) when a data request is made. So far I have this rough idea: Execution engine makes data request "Memory control" queries the L1 DTLB If the above misses, the L2 TLB is now queried At this point two things can happen, a miss or a hit: If its a hit the CPU tries L1D/L2/L3 caches, page table and then main memory/hard disk in that order? If its a