From owner-freebsd-arch@FreeBSD.ORG Tue Jun 5 13:39:02 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AFF81065675; Tue, 5 Jun 2012 13:39:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 017DB8FC1B; Tue, 5 Jun 2012 13:39:01 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q55Dcg18059915; Tue, 5 Jun 2012 16:38:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q55DcfIw099602; Tue, 5 Jun 2012 16:38:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q55DcefT099601; Tue, 5 Jun 2012 16:38:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Jun 2012 16:38:40 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120605133840.GK85127@deviant.kiev.zoral.com.ua> References: <201206041101.57486.jhb@freebsd.org> <20120604181917.GD85127@deviant.kiev.zoral.com.ua> <201206041722.07269.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEfPc/DjvCj+JzNg" Content-Disposition: inline In-Reply-To: <201206041722.07269.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: Fwd: [RFC] Kernel shared variables X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:39:02 -0000 --PEfPc/DjvCj+JzNg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 04, 2012 at 05:22:07PM -0400, John Baldwin wrote: > On Monday, June 04, 2012 2:19:17 pm Konstantin Belousov wrote: > > On Mon, Jun 04, 2012 at 11:01:57AM -0400, John Baldwin wrote: > > > On Sunday, June 03, 2012 6:49:27 am Bruce Evans wrote: > > > > On Sun, 3 Jun 2012, Konstantin Belousov wrote: > > > >=20 > > > > > On Sun, Jun 03, 2012 at 07:28:09AM +1000, Bruce Evans wrote: > > > > >> On Sat, 2 Jun 2012, Konstantin Belousov wrote: > > > > >>> ... > > > > >>> In fact, I think that if the whole goal is only fast clocks, th= en we > > > > >>> do not need any additional system mechanisms, since we can easi= ly export > > > > >>> coefficients for rdtsc formula already. E.g. we can put it into= elf auxv, > > > > >>> which is ugly but bearable. > > > > >> > > > > >> How do you get the timehands offsets? These only need to be upd= ated > > > > >> every second or so, or when used, but how can the application kn= ow > > > > >> when they need to be updated if this is not done automatically i= n the > > > > >> kernel by writing to a shared page? I can only think of the > > > > >> application arranging an alarm signal every second or so and upd= ating > > > > >> then. No good for libraries. > > > > > What is timehands offsets ? Do you mean things like leap seconds ? > > > >=20 > > > > Yes. binuptime() is: > > > >=20 > > > > % void > > > > % binuptime(struct bintime *bt) > > > > % { > > > > % struct timehands *th; > > > > % u_int gen; > > > > %=20 > > > > % do { > > > > % th =3D timehands; > > > > % gen =3D th->th_generation; > > > > % *bt =3D th->th_offset; > > > > % bintime_addx(bt, th->th_scale * tc_delta(th)); > > > > % } while (gen =3D=3D 0 || gen !=3D th->th_generation); > > > > % } > > > >=20 > > > > Without the kernel providing th->th_offset, you have to do lots of = ntp > > > > handling for yourself (compatibly with the kernel) just to get an > > > > accuracy of 1 second. Leap seconds don't affect CLOCK_MONOTONIC, b= ut > > > > they do affect CLOCK_REALTIME which is the clock id used by > > > > gettimeofday(). For the former, you only have to advance the offset > > > > for yourself occasionally (compatibly with the kernel) and manage > > > > (compatibly with the kernel, especially in the long term) ntp slewi= ng > > > > and other syscall/sysctl kernel activity that micro-adjusts th->th_= scale. > > >=20 > > > I think duplicating this logic in userland would just be wasteful. I= have > > > a private fast gettimeofday() at my current job and it works by expor= ting > > > the current timehands structure (well, the equivalent) to userland. = The > > > userland bits then fetch a copy of the details and do the same as bin= time(). > > > (I move the math (bintime_addx() and the multiply)) out of the loop h= owever. > > I started yesterday an implementation which uses shared page to export > > some variant of timehands, and uses auxv to provide the libc with a poi= nter > > to timehands when rdtsc is reasonable. > >=20 > > I almost finished both 32bit and 64bit userspace, but there is > > kernel-side work left. Is your implementation ready or close to be ready > > for commit ? In other words, should I drop the efforts, or continue ? >=20 > No, mine is not general purpose. I'll see if I can make a public patch o= f what > it looks like. My first version that seems to work on amd64 is at http://people.freebsd.org/~kib/misc/moronix.1.patch The plugs do allow for the new gettimeofday code to be replaced by vdso version in future. This is definitely WIP, in particular, the memory barriers handling in the __vdso_gettimeofday and in the tc_windup updater is missing. Also, clock_gettime() support would require ABI change. I only compiled amd64 kernel, i386 is probably broken, other architectures are definitely broken. --PEfPc/DjvCj+JzNg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/OC+AACgkQC3+MBN1Mb4gFvgCg7kdxK3EZJGiLz8SDf3/xTkEg XA8An0Mb5+KWdwgLW+SjCaI7UFY3ufJS =Ev9z -----END PGP SIGNATURE----- --PEfPc/DjvCj+JzNg--