Re: amd64: svs

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 09/01/2018 à 21:23, Jaromír Doleček a écrit :
> 2018-01-08 10:24 GMT+01:00 Maxime Villard <max%m00nbsd.net@localhost <mailto:max%m00nbsd.net@localhost>>:
>  > 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.

No - there are two separate address spaces, the kernel one and the user one. In
the user one, there should be only a few kernel pages mapped.

On return to user space, we switch to the user address space.

> Linux went with just completely separate address spaces for kernel and user
> space on the affected Intel cpus.

That's what we do, too. Doing this is faster than "unmapping the kernel pages
on return to user space".

Switching the address space costs one "movq %rax,%cr3".

As opposed to that, in order to "unmap the kernel pages on return to user
space" we need to zero out several uint64_t's and flush the TLB; which is
more time consuming.

> The address space switch could be made cheaper when cpu has PCID, which Linux
> already supports.

Yes, theoretically, but we don't support that.

> 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?

Yes, it would benefit if we added PCID.

> 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.

Probably, but there are still many CPUs without PCID out there, and for them
a blunt separation will unfortunately still be needed.

Maxime