Comment 3 for bug 1821441

I'm seeing the same thing. Basically, any use of clock_gettime now requires a syscall (isntead of using vsdo). The applications I'm running do a lot of clock_gettime's, and basically cannot run performantly anymore after this happens.

This machine is a:
System Information
        Manufacturer: Alienware
        Product Name: Alienware Aurora Ryzen Edition
        Version: 1.0.1

cpu:
processor : 31
vendor_id : AuthenticAMD
cpu family : 23
model : 113
model name : AMD Ryzen 9 3950X 16-Core Processor
stepping : 0
microcode : 0x8701013

kernel:
4.15.0-121-generic #123-Ubuntu SMP Mon Oct 5 16:16:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

kernel log after resuming from sleep:
Oct 14 15:28:59 viable kernel: [ 3442.068452] Measured 70 cycles TSC warp between CPUs, turning off TSC clock.
Oct 14 15:28:59 viable kernel: [ 3442.068455] tsc: Marking TSC unstable due to check_tsc_sync_source failed
Oct 14 15:28:59 viable kernel: [ 3442.068472] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Oct 14 15:28:59 viable kernel: [ 3442.068473] sched_clock: Marking unstable (3442081459163, -14096408)<-(3442040805073, 27665648)
Oct 14 15:28:59 viable kernel: [ 3442.068582] cache: parent cpu1 should not be sleeping
Oct 14 15:28:59 viable kernel: [ 3442.068845] CPU1 is up
Oct 14 15:28:59 viable kernel: [ 3442.067786] clocksource: Switched to clocksource hpet