Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Jun 2012 08:19:04 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Gianni <gianni@freebsd.org>, Alan Cox <alc@rice.edu>, Alexander Kabaev <kan@freebsd.org>, Attilio Rao <attilio@freebsd.org>, Konstantin Belousov <kib@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: Fwd: [RFC] Kernel shared variables
Message-ID:  <20120603051904.GG2358@deviant.kiev.zoral.com.ua>
In-Reply-To: <20120603063330.H3418@besplex.bde.org>
References:  <CACfq090r1tWhuDkxdSZ24fwafbVKU0yduu1yV2%2BoYo%2BwwT4ipA@mail.gmail.com> <20120601193522.GA2358@deviant.kiev.zoral.com.ua> <CAJ-FndC71=3Jo%2BBxQi==gCoLipBxj8X8XMBydjvrcKeGw%2BWOnA@mail.gmail.com> <20120602164847.GB2358@deviant.kiev.zoral.com.ua> <CAJ-FndAXFwuEspq%2BQeF0Hv1dr8JjREP=c=g3-abP=eoZ-D4hEg@mail.gmail.com> <CAJ-FndCpztSWyJo2hRVs5qu%2BvQOj9E1mPBhfVOxM_OC2eNac6A@mail.gmail.com> <20120602171632.GC2358@deviant.kiev.zoral.com.ua> <20120603063330.H3418@besplex.bde.org>

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

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

On Sun, Jun 03, 2012 at 07:28:09AM +1000, Bruce Evans wrote:
> On Sat, 2 Jun 2012, Konstantin Belousov wrote:
>=20
> >On Sat, Jun 02, 2012 at 06:00:06PM +0100, Attilio Rao wrote:
> >>...
> >>2012/6/2 Konstantin Belousov <kostikbel@gmail.com>:
> >>>On Sat, Jun 02, 2012 at 02:01:35PM +0100, Attilio Rao wrote:
> >[Tried to trim the text]
>=20
> [Trimmed more]
>=20
> >>>Right, exactly, and this is why I object to the "offsets" approach.
> >>>It basically moves us to the old times of the "jump tables" shared
> >>>libraries, that fortunately was never a case for FreeBSD even when
> >>>a.out was used.
> >>
> >>I'm objecting to this either.
> >My english is not good enough to understand this. Do you agree or disagr=
ee
> >with my statement that 'indexes' make it very hard to maintain ABI ?
>=20
> Syscall numbers are basically indexes, and work OK (because there aren't
> many of them even after ~30-35 years of accumulating them).
>=20
> >...
> >>The gettimeofday() implementation is a different story than what is ask=
ed=20
> >>here.
> >
> >But the goal is to have fast clocks, right ? What else is planned ?
> >
> >In fact, I think that if the whole goal is only fast clocks, then we
> >do not need any additional system mechanisms, since we can easily export
> >coefficients for rdtsc formula already. E.g. we can put it into elf auxv,
> >which is ugly but bearable.
>=20
> How do you get the timehands offsets?  These only need to be updated
> every second or so, or when used, but how can the application know
> when they need to be updated if this is not done automatically in the
> kernel by writing to a shared page?  I can only think of the
> application arranging an alarm signal every second or so and updating
> then.  No good for libraries.
What is timehands offsets ? Do you mean things like leap seconds ?
This is indeed problematic for auxv. For auxv it could be solved by
providing offset for next recheck using syscalls, and making libc code to
respect this offset. But, I do think that vdso in shared page
is the right solution, not auxv.

>=20
> rdtsc is also very unportable, even on CPUs that have it.  But all other
> x86 timecounter hardware is too slow if you want gettimeofday() to be fast
> and as accurate as it is now.
!rdtsc hardware is probably cannot be used at all due to need to provide
usermode access to device registers. The mere presence of rdtsc does not
means that usermode indeed can use it, it should be decided by kernel
based on the current in-kernel time source. If rdtsc is not usable, the
corresponding data should not be exported, or implementation should go
directly into syscall or whatever.

In fact, I would be very grateful if an expert in time-keeping provided
concise description of the algorithm for translating rdtsc output into
struct timeval, also enumerating required parameters.

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

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

iEYEARECAAYFAk/K88gACgkQC3+MBN1Mb4glQwCg1YIEeb2XDWk6r2fPtZ1/5rB0
yfYAoIXaW0zTrBFZOBQHEVFDhV1t/pNY
=N/wE
-----END PGP SIGNATURE-----

--eEhvUqzJgUABKnxr--



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