On 08/01/15 15:06, Imre Palik wrote: > On 01/07/15 17:30, Ian Campbell wrote: >> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote: >>> From: "Palik, Imre" <im...@amazon.de> >>> >>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to >>> be used) instead of the Xen clocksource should not cause any issues, as >>> Dom0 VMs never live-migrated. >> >> Is this still true given that dom0's vcpus are migrated amongst pcpus on >> the host? The tsc are not synchronised on some generations of hardware >> so the result there would be the TSC appearing to do very odd things >> under dom0's feet. Does Linux cope with that or does it not matter for >> some other reason? > > First of all, if the initial pcpus are not synchronised, linux won't consider > TSC as a viable clocksource. > > If the initial pcpus are synchronised, but then the dom0 vcpus are migrated to > unsynchronised pcpus, then hopefully the tsc watchdog catches the issue, and > the kernel falls back to the xen clocksource. The issue here is that the > watchdog can only detect clock skews bigger than 0.0625s/0.5s. Hopefully this > is enough to avoid the weirdest things.
I don't think any such hardware exists. Either TSC is synchronized across all CPUs or none. > Also, some parts of the kernel (e.g., scheduling) will always use the paravirt > clock. No matter what priorities are set. > > So it should be safe for some definition of safe. > But I was unable to test it on a hardware platform that would hit the > problematic > case described above. Ok. Can you list the various time sources and their ratings in the commit message for clarity. i.e, to justify 275 (below TSC = 300. above hpet = 250). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
