From owner-freebsd-arch@FreeBSD.ORG Sun Jun 3 05:19:11 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 DD0C6106564A; Sun, 3 Jun 2012 05:19:11 +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 5DDF48FC0A; Sun, 3 Jun 2012 05:19:11 +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 q535J5Qr016796; Sun, 3 Jun 2012 08:19:05 +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 q535J4m1082109; Sun, 3 Jun 2012 08:19:04 +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 q535J4j0082108; Sun, 3 Jun 2012 08:19:04 +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: Sun, 3 Jun 2012 08:19:04 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120603051904.GG2358@deviant.kiev.zoral.com.ua> References: <20120601193522.GA2358@deviant.kiev.zoral.com.ua> <20120602164847.GB2358@deviant.kiev.zoral.com.ua> <20120602171632.GC2358@deviant.kiev.zoral.com.ua> <20120603063330.H3418@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eEhvUqzJgUABKnxr" Content-Disposition: inline In-Reply-To: <20120603063330.H3418@besplex.bde.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: Gianni , Alan Cox , Alexander Kabaev , Attilio Rao , Konstantin Belousov , 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: Sun, 03 Jun 2012 05:19:11 -0000 --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 : > >>>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--