4 ms·
I heard that, especially with spectre, most of the cost of context switching comes from messing up your caches + TLB (https://blog.tsunanet.net/2010/11/how-long
by why_only_15 7y ago
I heard that, especially with spectre, most of the cost of context switching comes from messing up your caches + TLB (https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-m...). There's a graph on Dan Luu's blog about how it takes 14,000 cycles to get back to full performance after a syscall: https://danluu.com/images/new-cpu-features/flexsc_ipc_recovery.png https://danluu.com/images/new-cpu-features/flexsc_ipc_recove....
- foota 7y agoI wonder if it would be possible (& worth doing, since it would require cross cutting work) to enable saving and loading cache hit profiles
- why_only_15 7y agoWhat do you mean? If you can record the data in the first place you can probably save it. If you mean making some kind of workload or benchmark, couldn't you write some code to do it? It's probably somewhat inefficient because you can't write to it directly but you can get pretty close.
- saagarjha 7y agoSounds like something profile-guided optimization might do.
- dfox 7y agoThe problem is that on i386 the TLB entries are keyed only by linear address and not by page table that the entry came from and writing into the page table register (even rewriting the same value) is documented as triggering TLB flush. On typical RISC platforms that directly expose TLB to supervisor TLB entries usually have few bits that can be used to record for which process is the entry valid and thus there is no need to flush whole TLB on each task switch. (Modern i386 CPUs actually have somewhat similar mechanism, but it is only usable by hypervisors, not by normal operating systems)