2018-01-08 10:24 GMT+01:00 Maxime Villard <[email protected]>: > > As far as SVS is concerned, it is not needed: each time an L4 slot is added > (pmap_get_ptp) or removed (pmap_free_ptp), SVS only applies the change in the > user page tables. > > The TLB is then flushed as usual: the slots that are stale in the pmap page > tables are also stale in the user page tables, so the flush has the same effect > regardless of whether the CPU is executing in userland or in the kernel. > > There are possible optimizations, like not sending TLB-flush IPIs to CPUs that > are known to have performed a kernel<->user transition between the time when a > page got removed from the page tables and the time we decided to flush the TLB > as a result.
If I understand correctly, basically main idea is that we keep the same address space, but simply unmap kernel pages on return to user space. Linux went with just completely separate address spaces for kernel and user space on the affected Intel cpus. The address space switch could be made cheaper when cpu has PCID, which Linux already supports. Do you reckon SVS has potential of having lower overall overhead than separate address spaces + PCID? Alternatively, do you think SVS would benefit if we added PCID support to x86 pmap? Since we already have support for Alpha ASN which is similar concept as the x86 PCID, perhaps it would not be overly complex to implement the PCID support. Jaromir
