3 ms·
One of the entire points of a unikernel is that you don't have to do a TLB flush on context switch, which especially post-Meltdown is very expensive...because y
by chc4 4y ago
One of the entire points of a unikernel is that you don't have to do a TLB flush on context switch, which especially post-Meltdown is very expensive...because you never change your page table or have context switches! Having a seperate kernel memory map gets rid of that entirely.
- eyberg 4y agoFor a kernel<>user yes, however you don't do the TLB flush for every type of switch. For instance thread<>thread you wouldn't and if you are single process there is no process<>process switch which is very expensive. It is still possible to get much greater performance this way without having to cut corners. We routinely benchmark applications such as go/rust performing significantly better because of this. As for needing to change page tables - you need to deal with that regardless. To dig deeper there is an awful lot going on in say linux to deal with the fact that you have many different programs and (users) running on the same system. Whether it is shared memory or the scheduler itself - there is a ton of work that goes into that and by explicitly not supporting that you can make lots of gains. I don't think we are trying to promote a purist approach to this - we're trying to be pragmatic.