Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2012 20:28:39 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Fast gettimeofday(2) and clock_gettime(2)
Message-ID:  <20120607172839.GZ85127@deviant.kiev.zoral.com.ua>
In-Reply-To: <201206070850.55751.jhb@freebsd.org>
References:  <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <201206061423.53179.jhb@freebsd.org> <20120606205938.GS85127@deviant.kiev.zoral.com.ua> <201206070850.55751.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--YBGzgpgHAney5ErF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 07, 2012 at 08:50:55AM -0400, John Baldwin wrote:
> On Wednesday, June 06, 2012 4:59:38 pm Konstantin Belousov wrote:
> > On Wed, Jun 06, 2012 at 02:23:53PM -0400, John Baldwin wrote:
> > > On Wednesday, June 06, 2012 12:51:15 pm Konstantin Belousov wrote:
> > > > A positive result from the recent flame-bait on arch@ is the working
> > > > implementation of the fast gettimeofday(2) and clock_gettime(2). The
> > > > speedup I see is around 6-7x on the 2600K. I think the speedup could
> > > > be even bigger on the previous generation of CPUs, where lock
> > > > operations and syscall entry are costlier. A sample test runs of
> > > > tools/tools/syscall_timing are presented at the end of message.
> > >=20
> > > In general this looks good but I see a few nits / races:
> > >=20
> > > 1) You don't follow the model of clearing tk_current to 0 while you
> > >    are updating the structure that the in-kernel timecounter code
> > >    uses.  This also means you have to avoid using a tk_current of 0
> > >    and that userland has to keep spinning as long as tk_current is 0.
> > >    Without this I believe userland can read a partially updated
> > >    structure.
> > I changed the code to be much more similar to the kern_tc.c. I (re)added
> > the generation field, which is set to 0 upon kernel touching timehands.
>=20
> Thank you.  BTW, I think we should use atomic_load_acq_int() on both acce=
sses=20
> to th_gen (and the in-kernel binuptime should do the same).  I realize th=
is
> requires using rmb before the while condition in userland since we can't
> use atomic_load_acq_int() here.  I think it should also use=20
> atomic_store_rel_int() for both stores to th_gen during the tc_windup()
> callback.
This is done. On the other hand, I removed a store_rel from updating
tk_current, since it is after enabling store to th_gen, and the order
there does not matter.

I also did some restructuring of the userspace, removing layers that
Bruce did not liked. Now top-level functions directly call binuptime().
I also shortened the preliminary operations by caching timekeep pointer.
Its double-initialization is safe.

Latest version is at
http://people.freebsd.org/~kib/misc/moronix.4.patch

I probably move all shared page helpers to separate file from kern_exec.c,
but this will happen after moronix is committed.

--YBGzgpgHAney5ErF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk/Q5McACgkQC3+MBN1Mb4goxQCg1CEB9/qDJ7WNNVdNleSpqiUS
kZwAniRrYMNQOjHycMeeoCOu4ixtChdl
=j52Z
-----END PGP SIGNATURE-----

--YBGzgpgHAney5ErF--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120607172839.GZ85127>