lkml.org 
[lkml]   [2017]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2017-01-20 15:57    [W:0.097 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site