From owner-freebsd-arch@FreeBSD.ORG Mon Jun 4 21:30:16 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 DC4501065678; Mon, 4 Jun 2012 21:30:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 96ECE8FC14; Mon, 4 Jun 2012 21:30:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ECFD9B94F; Mon, 4 Jun 2012 17:30:14 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Mon, 4 Jun 2012 17:22:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <201206041101.57486.jhb@freebsd.org> <20120604181917.GD85127@deviant.kiev.zoral.com.ua> In-Reply-To: <20120604181917.GD85127@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206041722.07269.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 04 Jun 2012 17:30:15 -0400 (EDT) Cc: Gianni , Alan Cox , Alexander Kabaev , Attilio Rao , 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: Mon, 04 Jun 2012 21:30:16 -0000 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: > > > > > > > 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, 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. > > > >> > > > >> 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 ? > > > > > > Yes. binuptime() is: > > > > > > % void > > > % binuptime(struct bintime *bt) > > > % { > > > % struct timehands *th; > > > % u_int gen; > > > % > > > % do { > > > % th = timehands; > > > % gen = th->th_generation; > > > % *bt = th->th_offset; > > > % bintime_addx(bt, th->th_scale * tc_delta(th)); > > > % } while (gen == 0 || gen != th->th_generation); > > > % } > > > > > > 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, but > > > 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 slewing > > > and other syscall/sysctl kernel activity that micro-adjusts th->th_scale. > > > > 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 exporting > > the current timehands structure (well, the equivalent) to userland. The > > userland bits then fetch a copy of the details and do the same as bintime(). > > (I move the math (bintime_addx() and the multiply)) out of the loop however. > I started yesterday an implementation which uses shared page to export > some variant of timehands, and uses auxv to provide the libc with a pointer > to timehands when rdtsc is reasonable. > > 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 ? No, mine is not general purpose. I'll see if I can make a public patch of what it looks like. -- John Baldwin