From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 10:41:50 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 978763A2; Sun, 10 Feb 2013 10:41:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E98E0369; Sun, 10 Feb 2013 10:41:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1AAfjuT071977; Sun, 10 Feb 2013 12:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1AAfjuT071977 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1AAfjXo071976; Sun, 10 Feb 2013 12:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Feb 2013 12:41:45 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <20130210104145.GJ2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <1360365220.4545.42.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+gGPykIdtTMJQYdC" Content-Disposition: inline In-Reply-To: <1360365220.4545.42.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 10:41:50 -0000 --+gGPykIdtTMJQYdC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 04:13:40PM -0700, Ian Lepore wrote: > On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote: > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > I'd like feedback on the attached patch, which adds support to our > > > time_pps_fetch() implementation for the blocking behaviors described = in > > > section 3.4.3 of RFC 2783. The existing implementation can only retu= rn > > > the most recently captured data without blocking. These changes add = the > > > ability to block (forever or with timeout) until a new event occurs. > > >=20 > > > -- Ian > > >=20 > >=20 > > > Index: sys/kern/kern_tc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/kern/kern_tc.c (revision 246337) > > > +++ sys/kern/kern_tc.c (working copy) > > > @@ -1446,6 +1446,50 @@ > > > * RFC 2783 PPS-API implementation. > > > */ > > > =20 > > > +static int > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > +{ > > > + int err, timo; > > > + pps_seq_t aseq, cseq; > > > + struct timeval tv; > > > + > > > + if (fapi->tsformat && fapi->tsformat !=3D PPS_TSFMT_TSPEC) > > > + return (EINVAL); > > > + > > > + /* > > > + * If no timeout is requested, immediately return whatever values w= ere > > > + * most recently captured. If timeout seconds is -1, that's a requ= est > > > + * to block without a timeout. WITNESS won't let us sleep forever > > > + * without a lock (we really don't need a lock), so just repeatedly > > > + * sleep a long time. > > > + */ > > Regarding no need for the lock, it would just move the implementation i= nto > > the low quality one, for the case when one timestamp capture is lost > > and caller of time_pps_fetch() sleeps until next pps event is generated. > >=20 > > I understand the desire to avoid lock, esp. in the pps_event() called > > from the arbitrary driver context. But the race is also real. > >=20 >=20 > What race? A user of the pps interface understands that there is one > event per second, and understands that if you ask to block until the > next event at approximately the time that event is expected to occur, > then it is ambiguous whether the call completes almost-immediately or in > about 1 second. >=20 > Looking at it another way, if a blocking call is made right around the > time of the PPS, the thread could get preempted before getting to > pps_fetch() function and not get control again until after the PPS has > occurred. In that case it's going to block for about a full second, > even though the call was made before top-of-second. That situation is > exactly the same with or without locking, so what extra functionality is > gained with locking? What guarantee does locking let us make to the > caller that the lockless code doesn't? No guarantees, but I noted in the original reply that this is about the quality of the implementation and not about correctness. As I said there as well, I am not sure that any locking can be useful for the situation at all. --+gGPykIdtTMJQYdC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRF3loAAoJEJDCuSvBvK1BdfkQAJ23vyNMtY8Hsue3Vvf1uHd8 pJFQr/6NBIeaCIH057H6G8aWzmEUStoY7Gve8mzFr0oBo0zkb6ttTjINkbvaNI0T 48htcdEUx+elnFs8bIzlPstEsluJGg4TcJG3NbVBJzu1Hmjyt6MqsgbI9kOyJpmB X1JjwMDNT0TiPL8gSKJcNMFT2FYc2186Ol4vVyeBS3oQCnzFHSfUpvF350felDo5 8sS0A50E1owRdcNje8FWtShwFmVHIVgwSbuSMaf5Ga4ks2eupc4HUtCYQAxumOzY P+NLlOfEWSmzQfDbkXk1527CGn6lKai+SZVXOp9OY081XcwEbuLZjja84JK9WyQ3 hb+RMOPY6tEMxYg4VrkeuskMV3S0H95EHP09/3neHOjxRDqFPgk+plLe3r4zkQLw up72SO7VEMqvsN8R8vXtN89uetUaC50LbcV15iLdplZRtcQcIgkq6oAV/9131IUK EkZeRGBJMGeM78wRdSnPilB7zpxLcBe0U7WXkvmbB3n0nAfsQRj3QVi6YGzDZ6Cq 0SZm1oQUUFyPjja+afdjOmIy69G6WbrA1AY2YqSHV7/65sYqg7bQEXwvEDfbGgik xfsYqBe/DQHnluSpjgRyRK2pXIQmu5T6NP7PFJBcl2e6ASWQhJZA3rCSSWiH8Gjf T8VOLEKByW58VUFEZc1+ =uLon -----END PGP SIGNATURE----- --+gGPykIdtTMJQYdC--