Messages in this thread | | | Date | Fri, 20 Jan 2017 11:52:58 -0200 | From | Marcelo Tosatti <> | Subject | Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure |
| |
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.
| |