Differential D27629
x86: stop punishing VMs with low priority for TSC timecounter Authored by kib on Dec 16 2020, 9:34 AM. Tags None Referenced Files
Details I suspect that virtualization techniques improved from the time when we have to effectively disable TSC use in VM. For instance, it was reported (complained) in https://github.com/JuliaLang/julia/issues/38877 that FreeBSD is groundlessly slow on AWS with some loads. I propose to remove the check and watch for complaints.
Diff Detail
Event TimelineComment Actions This is fine with me; we need to make sure it's adequately publicized so that folks know to report issues. Would it make sense to add a printf on boot reporting something like "Using TSC in VM guest, please report ..."? Or do we think it's sufficiently likely that VM TSC issues are irrelevant today that it's not necessary? Comment Actions No, but maybe someone would review dmesg if they run into trouble. Anyway I guess we have evidence that the current no-TSC-on-VM is suboptimal and notification made it to you so presumably trouble the opposite way would also end up reported somehow. Comment Actions I added @cperciva to the review in hope that he would test or at least provide an opinion about AWS. AWS was the origin of the complains that lead to this change, but I do not think that people followed my advice. I believe AWS user population is big enough to warrant the flip of defaults, even if some less important hypervisors would require manual tweaks (but I doubt). Comment Actions Sorry, I've been mostly AFK due to recovering from my flu shot. Poor performance of time-related syscalls is something I've noticed in AWS but never got around to chasing down. In one case I saw a dramatic improvement from switching over to TSC but I wasn't sure if it was safe. FreeBSD runs on two x86 environments in EC2: Xen and Nitro (which looks like KVM). On Xen, Amazon recommends using the TSC, while on Nitro they recommend kvm-clock. |