On Fri, Jan 20, 2017 at 02:36:40PM +0100, Paolo Bonzini wrote: > > > On 20/01/2017 14:07, Marcelo Tosatti wrote: > > On Fri, Jan 20, 2017 at 01:55:27PM +0100, Paolo Bonzini wrote: > >> > >> > >> On 20/01/2017 13:20, Marcelo Tosatti wrote: > >>> kernel/time/timekeeping.c | 79 +++++++++++++++++++++++++++++++++++++++ > >> > >> Why not leave this in drivers/ptp/ptp_chardev.c? > > > > timekeeper_lock > > Why does emulate_ptp_sys_offset need it, if the current PTP_SYS_OFFSET > code doesn't? Because if time is adjusted while you are taking the samples, the mean can return non existant values: 1) take sample1 (realtime = 2000) 2) userspace changes realtime (realtime = 100) 3) 2100/2 = 1050 However that 1050 value never existed, before or after userspace changed realtime. Such behaviour does not exist with PTP_SYS_OFFSET, because taking getnstimeofday64 is serialized against time changes. I am not sure whether returning such bizzare values is fine, to drop the lock. Hum... i think it must be because userspace will consider the new values after realtime is changed as correct. > Is the latency acceptable (considering this is a raw spin > lock) or is there a seqlock that we can use instead (such as tk_core.seq > like in get_device_system_crosststamp)? Well can move it after the ->getcrosststamp loop. I'll just drop the spinlock and document the behaviour. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
