From nobody@FreeBSD.org  Mon Aug  8 22:09:13 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0BD08106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  8 Aug 2011 22:09:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id EFD758FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  8 Aug 2011 22:09:12 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p78M9CJp098276
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 8 Aug 2011 22:09:12 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p78M9Csn098275;
	Mon, 8 Aug 2011 22:09:12 GMT
	(envelope-from nobody)
Message-Id: <201108082209.p78M9Csn098275@red.freebsd.org>
Date: Mon, 8 Aug 2011 22:09:12 GMT
From: Ashley <ashley.wil@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: dtrace  walltimestamp and timestamp functions incomplete
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         159612
>Category:       kern
>Synopsis:       [dtrace] [patch] walltimestamp and timestamp functions incomplete
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gnn
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 08 22:10:14 UTC 2011
>Closed-Date:    Sun Dec 29 18:12:07 UTC 2013
>Last-Modified:  Sun Dec 29 18:12:07 UTC 2013
>Originator:     Ashley
>Release:        9 beta1
>Organization:
>Environment:
FreeBSD shikai 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Tue Aug  2 09:35:34 EST 2011     root@shikai:/usr/obj/usr/src/sys/SHIKAI  amd64

>Description:
walltimestamp and timestamp don't appear to be right in BETA-1:


# dtrace -qn 'syscall::exec*:return { printf("%Y %s\n",walltimestamp,curpsinfo->pr_psargs); }'
1970 Jan  1 10:00:00 date
1970 Jan  1 10:00:00 ping
1970 Jan  1 10:00:00 ls


# dtrace -qn 'syscall::exec*:return { printf("%Y %s\n",timestamp,curpsinfo->pr_psargs); }'
1970 Jan  6 12:02:27 ping
1970 Jan  6 12:02:29 ls
1970 Jan  6 12:02:31 dtrace


# date
Sun Aug  7 19:47:02 EST 2011


dmesg:

dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX
dtrace_gethrestime(459): XXX



These functions don't appear to be complete:

uint64_t
dtrace_gethrestime(void)
{
        printf("%s(%d): XXX\n",__func__,__LINE__);
        return (0);
}


>How-To-Repeat:
dtrace -qn 'syscall::exec*:return { printf("%Y %s\n",walltimestamp,curpsinfo-pr_psargs); }'
>Fix:


>Release-Note:
>Audit-Trail:

From: Andriy Gapon <avg@FreeBSD.org>
To: bug-followup@FreeBSD.org, ashley.wil@gmail.com
Cc:  
Subject: Re: amd64/159612: dtrace  walltimestamp and timestamp functions incomplete
Date: Tue, 09 Aug 2011 12:45:55 +0300

 You are completely correct about walltimestamp.
 I am not sure what problem you perceive with timestamp though.
 
 -- 
 Andriy Gapon
Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Aug 14 10:32:31 UTC 2011 
Responsible-Changed-Why:  
Most likely not amd64-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=159612 

From: Fabian Keil <fk@fabiankeil.de>
To: bug-followup@FreeBSD.org
Cc: ashley.wil@gmail.com, Andriy Gapon <avg@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions
 incomplete
Date: Sun, 24 Jun 2012 15:34:21 +0200

 --Sig_/XTu3iD5adcBI3uKvVE.eD/i
 Content-Type: multipart/mixed; boundary="MP_/IIPfuo+xn64ZrhajrzOaxRo"
 
 --MP_/IIPfuo+xn64ZrhajrzOaxRo
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 The attached patch adds support for walltimestamp on amd64 and
 i386 by copying the code from mips. I only tested it on amd64.
 
 The problem perceived with timestamp was the result of a
 misunderstanding as confirmed in:
 http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026733.html
 
 Fabian
 
 --MP_/IIPfuo+xn64ZrhajrzOaxRo
 Content-Type: text/x-patch
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment;
  filename=0001-dtrace-Add-support-for-walltimestamp-on-amd64-and-i3.patch
 
 =46rom ac8877b5b0417d6177e59df7e63744a3c69497cc Mon Sep 17 00:00:00 2001
 From: Fabian Keil <fk@fabiankeil.de>
 Date: Sun, 24 Jun 2012 15:19:46 +0200
 Subject: [PATCH] dtrace: Add support for walltimestamp on amd64 and i386
 
 Code copied from mips.
 ---
  sys/cddl/dev/dtrace/amd64/dtrace_subr.c |    7 +++++--
  sys/cddl/dev/dtrace/i386/dtrace_subr.c  |    7 +++++--
  2 files changed, 10 insertions(+), 4 deletions(-)
 
 diff --git a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c b/sys/cddl/dev/dtrace/=
 amd64/dtrace_subr.c
 index 9960fa9..2d42ce2 100644
 --- a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 @@ -461,8 +461,11 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	struct      timespec curtime;
 +
 +	getnanotime(&curtime);
 +
 +	return (curtime.tv_sec * 1000000000UL + curtime.tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See amd64/amd64/trap.c */
 diff --git a/sys/cddl/dev/dtrace/i386/dtrace_subr.c b/sys/cddl/dev/dtrace/i=
 386/dtrace_subr.c
 index cef6914..3a1677a 100644
 --- a/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 @@ -462,8 +462,11 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	struct      timespec curtime;
 +
 +	getnanotime(&curtime);
 +
 +	return (curtime.tv_sec * 1000000000UL + curtime.tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See i386/i386/trap.c */
 --=20
 1.7.10.3
 
 
 --MP_/IIPfuo+xn64ZrhajrzOaxRo--
 
 --Sig_/XTu3iD5adcBI3uKvVE.eD/i
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk/nF2UACgkQSMVSH78upWOi4gCfR0/f1VxhprZAQAh48SJKAKda
 unUAn1RTccEMuHwYAshlKlFRy7OwiM50
 =e5Ai
 -----END PGP SIGNATURE-----
 
 --Sig_/XTu3iD5adcBI3uKvVE.eD/i--
Responsible-Changed-From-To: freebsd-bugs->gnn 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Jun 24 17:10:19 UTC 2012 
Responsible-Changed-Why:  
perhaps gnn can evaluate this patch? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=159612 

From: Fabian Keil <fk@fabiankeil.de>
To: Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com, Andriy Gapon
 <avg@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions
 incomplete
Date: Sun, 24 Jun 2012 22:57:01 +0200

 --Sig_/negw28FdcgnHeL64PUHjg31
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 Fabian Keil <fk@fabiankeil.de> wrote:
 
 > The attached patch adds support for walltimestamp on amd64 and
 > i386 by copying the code from mips. I only tested it on amd64.
 
 As Andriy suspected, the patch causes the system to
 panic when using walltimestamp inside probes for
 "fbt::getnanotime:".
 
 Fabian
 
 --Sig_/negw28FdcgnHeL64PUHjg31
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk/nfyEACgkQSMVSH78upWNPWgCcCuRRb/1dJbeG3qYnNSe/iHzj
 8bMAniZaGarTNhd9d6zDcaADfRg+ac2s
 =SSPX
 -----END PGP SIGNATURE-----
 
 --Sig_/negw28FdcgnHeL64PUHjg31--

From: Fabian Keil <fk@fabiankeil.de>
To: bug-followup@FreeBSD.org
Cc: ashley.wil@gmail.com, Andriy Gapon <avg@FreeBSD.org>, George
 Neville-Neil <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions
 incomplete
Date: Thu, 28 Jun 2012 18:08:15 +0200

 --Sig_/xb+Q4h=KqJGWvZH1U0Dpdkc
 Content-Type: multipart/mixed; boundary="MP_/qdb=LtBjKKfSlHkjl=t6TAr"
 
 --MP_/qdb=LtBjKKfSlHkjl=t6TAr
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 Fabian Keil <fk@fabiankeil.de> wrote:
 
 > Fabian Keil <fk@fabiankeil.de> wrote:
 >=20
 > > The attached patch adds support for walltimestamp on amd64 and
 > > i386 by copying the code from mips. I only tested it on amd64.
 >=20
 > As Andriy suspected, the patch causes the system to
 > panic when using walltimestamp inside probes for
 > "fbt::getnanotime:".
 
 I updated the patch to let it produce outdated walltimestamp values
 in cases where the previous version would have triggered a panic.
 
 This is certainly not ideal, but given that those cases are
 rather rare it might be better than having no walltimestamp
 support at all.
 
 It certainly shouldn't matter for the common use case of
 printf("%Y", walltimestamp) which doesn't even require
 millisecond precision.
 
 I changed getnanotime() to nanotime() as the former would
 only advance the walltimestamp roughly every 40 calls
 in frequently firing probes.
 
 Here's a comparison timing the same syscalls with timestamp and
 walltimestamp deltas (C3 disabled to workaround kern/169379):
 
 (timestamp deltas)
 --------------------------------------------- Monitoring vlc-static -------=
 --------------------------------------
 syscall             calls total         sum(ms)         avg(ns)         min=
 (ns)         max(ns)
 [...]
 open                       1441             118           82497            =
 7995        18554649
 access                     1288             308          239511           1=
 0912        26838286
 stat                       6486             508           78449            =
 8928        16976673
 wait4                         2            1594       797217060       17327=
 0874      1421163246
 sendmsg                   13260            1749          131927           1=
 0211         1550352
 getdirentries               672            2219         3303005            =
 8225        30652595
 ioctl                    880231            8093            9195            =
 3739         1775701
 writev                   127814           18365          143688            =
 5113        14737217
 clock_gettime          22212942          139441            6277            =
 2662        21776114
 read                    4056749          148426           36587            =
 3058       185536185
 write                    526677         2349660         4461294            =
 4145        43210601
 sigwait                       2         4338047   2169023509438      129478=
 0112   4336752238765
 nanosleep                650335         5996048         9219938         105=
 7541       329760375
 poll                     295670         8687444        29382231            =
 3383    320084200294
 _umtx_op               11056587        37340218         3377192            =
 3078   4336799189571
 
 ########
 
 (walltimestamp deltas)
 --------------------------------------------- Monitoring vlc-static -------=
 --------------------------------------
 syscall             calls total         sum(ms)         avg(ns)         min=
 (ns)         max(ns)
 [...]
 open                       1441             133           92538           1=
 2083        18569679
 fpathconf                  7212             139           19366            =
 7822          482603
 access                     1288             322          250176           1=
 8229        26847476
 stat                       6486             578           89184           1=
 3480        16990987
 wait4                         2            1594       797247834       17328=
 4803      1421210866
 sendmsg                   13260            1943          146591           1=
 5924         1579810
 getdirentries               672            2230         3318892           1=
 3061        30667724
 ioctl                    880231           14972           17010            =
 7752         1792895
 writev                   127814           19745          154488            =
 9359        14753761
 read                    4056749          178320           43956            =
 7124       185549141
 clock_gettime          22212942          330986           14900            =
 7472        21791038
 write                    526677         2353929         4469398            =
 8172        43236501
 sigwait                       2         4338140   2169070395294      129482=
 0920   4336845969669
 nanosleep                650335         6003161         9230875         107=
 4020       329777528
 poll                     295670         8690396        29392217            =
 7404    320091124011
 _umtx_op               11056587        37436745         3385922            =
 7822   4336892899586
 
 ######
 
 (timestamp deltas)
 
   time in ns                                          clock_gettime
            value  ------------- Distribution ------------- count
             1024 |                                         0
             2048 |@@@                                      1489786
             4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@    20380999
             8192 |@                                        302500
            16384 |                                         18915
            32768 |                                         5378
            65536 |                                         4005
           131072 |                                         2840
           262144 |                                         899
           524288 |                                         1276
          1048576 |                                         4896
          2097152 |                                         1387
          4194304 |                                         50
          8388608 |                                         9
         16777216 |                                         2
         33554432 |                                         0
 
   time in ns                                          nanosleep
            value  ------------- Distribution ------------- count
           524288 |                                         0
          1048576 |                                         27
          2097152 |@                                        8734
          4194304 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@             462140
          8388608 |                                         678
         16777216 |@@@@@@@@@@@                              178640
         33554432 |                                         113
         67108864 |                                         0
        134217728 |                                         1
        268435456 |                                         2
        536870912 |                                         0
 
 (walltimestamp deltas)
 
   time in ns                                          clock_gettime
            value  ------------- Distribution ------------- count
             2048 |                                         0
             4096 |                                         186603
             8192 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@            16029158
            16384 |@@@@@@@@@@@                              5964696
            32768 |                                         13766
            65536 |                                         4264
           131072 |                                         3573
           262144 |                                         3228
           524288 |                                         1259
          1048576 |                                         4923
          2097152 |                                         1411
          4194304 |                                         50
          8388608 |                                         9
         16777216 |                                         2
         33554432 |                                         0
 
   time in ns                                          nanosleep
            value  ------------- Distribution ------------- count
           524288 |                                         0
          1048576 |                                         27
          2097152 |@                                        8203
          4194304 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@             462669
          8388608 |                                         680
         16777216 |@@@@@@@@@@@                              178640
         33554432 |                                         113
         67108864 |                                         0
        134217728 |                                         1
        268435456 |                                         2
        536870912 |                                         0
 
 So clearly walltimestamp deltas are more expensive that timestamp
 deltas, but other than that they seem usable as well.
 
 I used the attached script to analyze whether or not the
 (wall)timestamps go in the right direction. With syscall:::entry
 probes they do (on my system):
 
 walltimestamp:
 
   forward                                                     2516864
   total                                                       2516864
 
 timestamp:
 
   forward                                                     2516864
   total                                                       2516864
 
 But using fbt::nanotime:entry probes instead (the problematic case
 where the previous patch would panic) only about 90% of the walltimestamps
 advance the time:
 
 walltimestamp:
 
   no change                                                      5254
   backwards                                                     77187
   forward                                                      830112
   total                                                        912553
 
 timestamp:
 
   forward                                                      912553
   total                                                        912553
 
 This could probably be improved by using the most recent cached_time[]
 instead of cached_time[curcpu], but I didn't test this.
 
 Is this use case considered important?
 
 Fabian
 
 --MP_/qdb=LtBjKKfSlHkjl=t6TAr
 Content-Type: text/x-patch
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment;
  filename=0001-dtrace-Add-support-for-walltimestamp-on-amd64-and-i3.patch
 
 =46rom 39fb7cc697cfdba07f14b1e3a8c559f3f5686a77 Mon Sep 17 00:00:00 2001
 From: Fabian Keil <fk@fabiankeil.de>
 Date: Sun, 24 Jun 2012 15:19:46 +0200
 Subject: [PATCH] dtrace: Add support for walltimestamp on amd64 and i386
 
 Use nanotime() instead of getnanotime() (like on mips)
 as the latter is far too inaccurate.
 
 Only allow simultaneous calls to nanotime() in dtrace_gethrtime()
 on different cpus, otherwise return the value cached in the previous
 run. This prevents double faults if walltimestamp is used in probes
 for fbt::getnanotime:* at the cost of potentially slightly outdated
 walltimestamp values.
 
 As a side effect this patch prevents double faults caused by:
 
 dtrace:::BEGIN,
 fbt::printf:entry
 {
         printf("%Y\n", walltimestamp)
 }
 fbt::printf:return
 {
         printf("%Y\n", walltimestamp)
 }
 ---
  sys/cddl/dev/dtrace/amd64/dtrace_subr.c |   21 +++++++++++++++++++--
  sys/cddl/dev/dtrace/i386/dtrace_subr.c  |   21 +++++++++++++++++++--
  2 files changed, 38 insertions(+), 4 deletions(-)
 
 diff --git a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c b/sys/cddl/dev/dtrace/=
 amd64/dtrace_subr.c
 index 9960fa9..56d15c5 100644
 --- a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 @@ -461,8 +461,25 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	static int already_getting_time[MAXCPU];
 +	static struct timespec cached_time[MAXCPU];
 +	struct timespec current_time;
 +
 +	/*
 +	 * This function can be entered as the result of a probe for
 +	 * fbt::nanotime:* that is using walltimestamp itself.
 +	 * If such a probe exists, we do not want it to endlessly
 +	 * trigger itself, eventually causing a double fault.
 +	 */
 +	if (!already_getting_time[curcpu]) {
 +		already_getting_time[curcpu] =3D 1;
 +		nanotime(&current_time);
 +		cached_time[curcpu] =3D current_time;
 +		already_getting_time[curcpu] =3D 0;
 +	}
 +
 +	return (cached_time[curcpu].tv_sec * 1000000000UL +
 +	    cached_time[curcpu].tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See amd64/amd64/trap.c */
 diff --git a/sys/cddl/dev/dtrace/i386/dtrace_subr.c b/sys/cddl/dev/dtrace/i=
 386/dtrace_subr.c
 index cef6914..caaf71c 100644
 --- a/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 @@ -462,8 +462,25 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	static int already_getting_time[MAXCPU];
 +	static struct timespec cached_time[MAXCPU];
 +	struct timespec current_time;
 +
 +	/*
 +	 * This function can be entered as the result of a probe for
 +	 * fbt::nanotime:* that is using walltimestamp itself.
 +	 * If such a probe exists, we do not want it to endlessly
 +	 * trigger itself, eventually causing a double fault.
 +	 */
 +	if (!already_getting_time[curcpu]) {
 +		already_getting_time[curcpu] =3D 1;
 +		nanotime(&current_time);
 +		cached_time[curcpu] =3D current_time;
 +		already_getting_time[curcpu] =3D 0;
 +	}
 +
 +	return (cached_time[curcpu].tv_sec * 1000000000UL +
 +	    cached_time[curcpu].tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See i386/i386/trap.c */
 --=20
 1.7.10.3
 
 
 --MP_/qdb=LtBjKKfSlHkjl=t6TAr
 Content-Type: text/x-dsrc
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename=timestamp-sanity-checks.d
 
 #!/usr/sbin/dtrace -s
 
 #pragma D option quiet
 
 dtrace:::BEGIN
 {
         last_walltimestamp =3D 0;
         last_timestamp =3D 0;
 }
 
 syscall:::entry
 {
         @w["total"] =3D count();
         this->walltimestamp =3D walltimestamp;
         this->last_walltimestamp =3D last_walltimestamp;
 
         @t["total"] =3D count();
         this->timestamp =3D timestamp;
         this->last_timestamp =3D last_timestamp;
 }
 
 syscall:::entry
 /this->last_walltimestamp > this->walltimestamp/
 {
         @w["backwards"] =3D count();
 }
 
 syscall:::entry
 /this->last_walltimestamp < this->walltimestamp/
 {
         @w["forward"] =3D count();
 }
 
 syscall:::entry
 /this->last_walltimestamp =3D=3D this->walltimestamp/
 {
         @w["no change"] =3D count();
 }
 
 syscall:::entry
 /this->last_timestamp > this->timestamp/
 {
         @t["backwards"] =3D count();
 }
 
 syscall:::entry
 /this->last_timestamp < this->timestamp/
 {
         @t["forward"] =3D count();
 }
 
 syscall:::entry
 /this->last_timestamp =3D=3D this->timestamp/
 {
         @t["no change"] =3D count();
 }
 
 syscall:::entry
 {
         last_walltimestamp =3D this->walltimestamp;
         last_timestamp =3D this->timestamp;
 }
 
 tick-60sec,
 dtrace:::END
 {
         printf("-------------- %Y --------------\n", walltimestamp);
         printf("walltimestamp:\n");
         printa(@w);
         printf("\ntimestamp:\n");
         printa(@t);
 }
 
 --MP_/qdb=LtBjKKfSlHkjl=t6TAr--
 
 --Sig_/xb+Q4h=KqJGWvZH1U0Dpdkc
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk/sgXMACgkQSMVSH78upWM6SgCfYayLJKEQMQf1Ikx+MMeaYjlJ
 UhgAnR97tBlKMpkz7xEEFGHFD5DQ0Ogz
 =/BBj
 -----END PGP SIGNATURE-----
 
 --Sig_/xb+Q4h=KqJGWvZH1U0Dpdkc--

From: Andriy Gapon <avg@FreeBSD.org>
To: Fabian Keil <fk@fabiankeil.de>
Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com,
        George Neville-Neil <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions incomplete
Date: Mon, 02 Jul 2012 17:48:50 +0300

 on 24/06/2012 23:57 Fabian Keil said the following:
 > Fabian Keil <fk@fabiankeil.de> wrote:
 > 
 >> The attached patch adds support for walltimestamp on amd64 and
 >> i386 by copying the code from mips. I only tested it on amd64.
 > 
 > As Andriy suspected, the patch causes the system to
 > panic when using walltimestamp inside probes for
 > "fbt::getnanotime:".
 > 
 
 I am not sure if this synthetic test is a showstopper here, actually.
 But what about inlining body of getnanotime into dtrace_gethrestime (while perhaps
 applying some mathematical optimizations) ?
 I think that that should be possible and should solve the problem at hand.
 
 Well, because 'static struct timehands *volatile timehands' is static,
 dtrace_gethrestime would have to go sys/kern/kern_tc.c under KDTRACE_HOOKS.
 Or dtrace_gethrestime would be a wrapper around another "dtrace_"-prefixed
 function (e.g. dtrace_getnanotime), which would go to sys/kern/kern_tc.c.
 Alternatively, timehands variable can "unstatisized" / "globalized".
 
 Maybe this is worth discussing on hackers@.
 
 Also, regarding nanotime() vs getnanotime(), I see that in the latest publicly
 available version of OpenSolaris code they update time for dtrace_gethrestime()
 once per tick via dtrace_hres_tick().  So not sure if we should strive to be "more
 catholic than Pope".
 
 P.S. The magic about "dtrace_" prefix is that fbt won't created probes for
 functions starting with it to avoid the obvious "self-introspection" problems.
 
 -- 
 Andriy Gapon
 
 

From: Fabian Keil <fk@fabiankeil.de>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com, George Neville-Neil
 <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions
 incomplete
Date: Wed, 4 Jul 2012 18:14:24 +0200

 --Sig_/GwDxGRzFx1DFpI.OU.irlXS
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 Andriy Gapon <avg@FreeBSD.org> wrote:
 
 > I am not sure if this synthetic test is a showstopper here, actually.
 > But what about inlining body of getnanotime into dtrace_gethrestime (whil=
 e perhaps
 > applying some mathematical optimizations) ?
 > I think that that should be possible and should solve the problem at hand.
 
 I don't doubt that it's possible, but there are multiple (get)nanotime()
 implementations and my impression was that it would require quite a bit
 of code duplication.
 
 > Well, because 'static struct timehands *volatile timehands' is static,
 > dtrace_gethrestime would have to go sys/kern/kern_tc.c under KDTRACE_HOOK=
 S.
 > Or dtrace_gethrestime would be a wrapper around another "dtrace_"-prefixed
 > function (e.g. dtrace_getnanotime), which would go to sys/kern/kern_tc.c.
 > Alternatively, timehands variable can "unstatisized" / "globalized".
 >=20
 > Maybe this is worth discussing on hackers@.
 >=20
 > Also, regarding nanotime() vs getnanotime(), I see that in the latest pub=
 licly
 > available version of OpenSolaris code they update time for dtrace_gethres=
 time()
 > once per tick via dtrace_hres_tick().  So not sure if we should strive to=
  be "more
 > catholic than Pope".
 
 I agree that FreeBSD's walltimestamps don't have to be more accurate
 that on OpenSolaris or illumos, but it's unclear to me what the expected
 accuracy is there.
 
 All the documentation I'm aware of specifies that the value is
 given in nanoseconds, but how often it changes isn't mentioned.
 
 I used getnanotime() in an earlier version of the patch and the
 sanity check results were really poor:
 
   forward                                                        9958
   no change                                                    387545
   walltimestamps                                               397501
 
 I would expect always calling getnanotime() directly to be even
 less accurate than calling nanotime() once per clock tick (assuming
 kern.hz=3D1000).
 
 > P.S. The magic about "dtrace_" prefix is that fbt won't created probes for
 > functions starting with it to avoid the obvious "self-introspection" prob=
 lems.
 
 Good to know. Thanks.
 
 Fabian
 
 --Sig_/GwDxGRzFx1DFpI.OU.irlXS
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk/0a+IACgkQSMVSH78upWN86wCfa+f655ILegHS7zhr9f8bThHd
 S6cAn0SQho7OcRTNhAZuUNVrtYGSV4uv
 =uLnD
 -----END PGP SIGNATURE-----
 
 --Sig_/GwDxGRzFx1DFpI.OU.irlXS--

From: Andriy Gapon <avg@FreeBSD.org>
To: Fabian Keil <fk@fabiankeil.de>
Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com,
        George Neville-Neil <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions incomplete
Date: Wed, 04 Jul 2012 21:06:39 +0300

 on 04/07/2012 19:14 Fabian Keil said the following:
 > Andriy Gapon <avg@FreeBSD.org> wrote:
 > 
 >> I am not sure if this synthetic test is a showstopper here, actually.
 >> But what about inlining body of getnanotime into dtrace_gethrestime (while perhaps
 >> applying some mathematical optimizations) ?
 >> I think that that should be possible and should solve the problem at hand.
 > 
 > I don't doubt that it's possible, but there are multiple (get)nanotime()
 > implementations and my impression was that it would require quite a bit
 > of code duplication.
 
 Nope. There is only one nanotime and getnanotime and getnanotime is quite small.
 
 >> Well, because 'static struct timehands *volatile timehands' is static,
 >> dtrace_gethrestime would have to go sys/kern/kern_tc.c under KDTRACE_HOOKS.
 >> Or dtrace_gethrestime would be a wrapper around another "dtrace_"-prefixed
 >> function (e.g. dtrace_getnanotime), which would go to sys/kern/kern_tc.c.
 >> Alternatively, timehands variable can "unstatisized" / "globalized".
 >>
 >> Maybe this is worth discussing on hackers@.
 >>
 >> Also, regarding nanotime() vs getnanotime(), I see that in the latest publicly
 >> available version of OpenSolaris code they update time for dtrace_gethrestime()
 >> once per tick via dtrace_hres_tick().  So not sure if we should strive to be "more
 >> catholic than Pope".
 > 
 > I agree that FreeBSD's walltimestamps don't have to be more accurate
 > that on OpenSolaris or illumos, but it's unclear to me what the expected
 > accuracy is there.
 > 
 > All the documentation I'm aware of specifies that the value is
 > given in nanoseconds, but how often it changes isn't mentioned.
 
 Once per tick in OpenSolaris as I've said earlier.
 
 > I used getnanotime() in an earlier version of the patch and the
 > sanity check results were really poor:
 > 
 >   forward                                                        9958
 >   no change                                                    387545
 >   walltimestamps                                               397501
 > 
 > I would expect always calling getnanotime() directly to be even
 > less accurate than calling nanotime() once per clock tick (assuming
 > kern.hz=1000).
 > 
 >> P.S. The magic about "dtrace_" prefix is that fbt won't created probes for
 >> functions starting with it to avoid the obvious "self-introspection" problems.
 > 
 > Good to know. Thanks.
 
 -- 
 Andriy Gapon
 
 

From: Fabian Keil <fk@fabiankeil.de>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com, George Neville-Neil
 <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions
 incomplete
Date: Thu, 5 Jul 2012 16:32:10 +0200

 --Sig_/HLlEY/P2yM4Fc_6RJbVIg93
 Content-Type: multipart/mixed; boundary="MP_/p0jwU+TkxCvymDAc7Vzdz./"
 
 --MP_/p0jwU+TkxCvymDAc7Vzdz./
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 Andriy Gapon <avg@FreeBSD.org> wrote:
 
 > on 04/07/2012 19:14 Fabian Keil said the following:
 > > Andriy Gapon <avg@FreeBSD.org> wrote:
 > >=20
 > >> I am not sure if this synthetic test is a showstopper here, actually.
 > >> But what about inlining body of getnanotime into dtrace_gethrestime (w=
 hile perhaps
 > >> applying some mathematical optimizations) ?
 > >> I think that that should be possible and should solve the problem at h=
 and.
 > >=20
 > > I don't doubt that it's possible, but there are multiple (get)nanotime()
 > > implementations and my impression was that it would require quite a bit
 > > of code duplication.
 >=20
 > Nope. There is only one nanotime and getnanotime and getnanotime is quite=
  small.
 
 fk@r500 ~ $egrep "^(get)?nanotime" /usr/src/sys/kern/kern_tc.c
 nanotime(struct timespec *tsp)
 getnanotime(struct timespec *tsp)
 nanotime(struct timespec *tsp)
 getnanotime(struct timespec *tsp)
 
 The two getnanotime()s seem to currently boil down to the same
 code (something I previously missed), but the two nanotime()s don't.
 
 > >> Well, because 'static struct timehands *volatile timehands' is static,
 > >> dtrace_gethrestime would have to go sys/kern/kern_tc.c under KDTRACE_H=
 OOKS.
 
 The attached patch does that and it's indeed a lot less invasive
 than I suspected.
 
 > >> Or dtrace_gethrestime would be a wrapper around another "dtrace_"-pref=
 ixed
 > >> function (e.g. dtrace_getnanotime), which would go to sys/kern/kern_tc=
 .c.
 > >> Alternatively, timehands variable can "unstatisized" / "globalized".
 > >>
 > >> Maybe this is worth discussing on hackers@.
 > >>
 > >> Also, regarding nanotime() vs getnanotime(), I see that in the latest =
 publicly
 > >> available version of OpenSolaris code they update time for dtrace_geth=
 restime()
 > >> once per tick via dtrace_hres_tick().  So not sure if we should strive=
  to be "more
 > >> catholic than Pope".
 > >=20
 > > I agree that FreeBSD's walltimestamps don't have to be more accurate
 > > that on OpenSolaris or illumos, but it's unclear to me what the expected
 > > accuracy is there.
 > >=20
 > > All the documentation I'm aware of specifies that the value is
 > > given in nanoseconds, but how often it changes isn't mentioned.
 >=20
 > Once per tick in OpenSolaris as I've said earlier.
 
 Sorry, I meant that I haven't seen the connection documented anywhere.
 
 The walltimestamp description in the DTrace book is:
 "Nanoseconds since epoch (January 1, 1970)"
 which seems a bit misleading if the value only gets updated
 once per tick.
 
 > > I used getnanotime() in an earlier version of the patch and the
 > > sanity check results were really poor:
 > >=20
 > >   forward                                                        9958
 > >   no change                                                    387545
 > >   walltimestamps                                               397501
 
 Replacing syscall:::entry with tick-1msec it looks a lot better, though:
 
 -------------- 2012 Jul  4 23:18:43 --------------
 walltimestamp:
 
   no change                                                       101
   forward                                                     2147900
   total                                                       2148001
 
 timestamp:
 
   forward                                                     2148001
   total                                                       2148001
 
 > > I would expect always calling getnanotime() directly to be even
 > > less accurate than calling nanotime() once per clock tick (assuming
 > > kern.hz=3D1000).
 
 Apparently that's not the case.
 =20
 Fabian
 
 --MP_/p0jwU+TkxCvymDAc7Vzdz./
 Content-Type: text/x-patch
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment;
  filename=0001-dtrace-Add-support-for-walltimestamp-on-amd64-and-i386-dtrace_getnanotime.patch
 
 =46rom 221ea6b2457902de51a3d7f4a1fa334d9fd6b054 Mon Sep 17 00:00:00 2001
 From: Fabian Keil <fk@fabiankeil.de>
 Date: Sun, 24 Jun 2012 15:19:46 +0200
 Subject: [PATCH] dtrace: Add support for walltimestamp on amd64 and i386
 
 This is the same code as already used on mips except that
 the getnanotime() clone dtrace_getnanotime() is used, which
 due to its name doesn't get fbt probes and thus using
 walltimestamp inside fbt::getnanotime: probes isn't an issue.
 ---
  sys/cddl/dev/dtrace/amd64/dtrace_subr.c |    9 +++++++--
  sys/cddl/dev/dtrace/i386/dtrace_subr.c  |    9 +++++++--
  sys/kern/kern_tc.c                      |   21 +++++++++++++++++++++
  sys/sys/time.h                          |    3 +++
  4 files changed, 38 insertions(+), 4 deletions(-)
 
 diff --git a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c b/sys/cddl/dev/dtrace/=
 amd64/dtrace_subr.c
 index 9960fa9..7f17678 100644
 --- a/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
 @@ -31,6 +31,8 @@
   * Copyright (c) 2011, Joyent, Inc. All rights reserved.
   */
 =20
 +#define KDTRACE_HOOKS 1
 +
  #include <sys/param.h>
  #include <sys/systm.h>
  #include <sys/types.h>
 @@ -461,8 +463,11 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	struct timespec current_time;
 +
 +	dtrace_getnanotime(&current_time);
 +
 +	return (current_time.tv_sec * 1000000000UL + current_time.tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See amd64/amd64/trap.c */
 diff --git a/sys/cddl/dev/dtrace/i386/dtrace_subr.c b/sys/cddl/dev/dtrace/i=
 386/dtrace_subr.c
 index cef6914..7edd090 100644
 --- a/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 +++ b/sys/cddl/dev/dtrace/i386/dtrace_subr.c
 @@ -31,6 +31,8 @@
   * Copyright (c) 2011, Joyent, Inc. All rights reserved.
   */
 =20
 +#define KDTRACE_HOOKS 1
 +
  #include <sys/param.h>
  #include <sys/systm.h>
  #include <sys/types.h>
 @@ -462,8 +464,11 @@ dtrace_gethrtime()
  uint64_t
  dtrace_gethrestime(void)
  {
 -	printf("%s(%d): XXX\n",__func__,__LINE__);
 -	return (0);
 +	struct timespec current_time;
 +
 +	dtrace_getnanotime(&current_time);
 +
 +	return (current_time.tv_sec * 1000000000UL + current_time.tv_nsec);
  }
 =20
  /* Function to handle DTrace traps during probes. See i386/i386/trap.c */
 diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c
 index 12873bb..dd58c83 100644
 --- a/sys/kern/kern_tc.c
 +++ b/sys/kern/kern_tc.c
 @@ -17,6 +17,7 @@
  __FBSDID("$FreeBSD: src/sys/kern/kern_tc.c,v 1.210 2012/06/23 09:33:06 kib=
  Exp $");
 =20
  #include "opt_compat.h"
 +#include "opt_kdtrace.h"
  #include "opt_ntp.h"
  #include "opt_ffclock.h"
 =20
 @@ -959,6 +960,26 @@ getmicrotime(struct timeval *tvp)
 =20
  #endif /* FFCLOCK */
 =20
 +#ifdef KDTRACE_HOOKS
 +/*
 + * This is a clone of getnanotime and used for walltimestamps.
 + * The dtrace_ prefix prevents fbt from creating probes for
 + * it so walltimestamp can be safely used in all fbt probes.
 + */
 +void
 +dtrace_getnanotime(struct timespec *tsp)
 +{
 +	struct timehands *th;
 +	u_int gen;
 +
 +	do {
 +		th =3D timehands;
 +		gen =3D th->th_generation;
 +		*tsp =3D th->th_nanotime;
 +	} while (gen =3D=3D 0 || gen !=3D th->th_generation);
 +}
 +#endif
 +
  /*
   * System clock currently providing time to the system. Modifiable via sys=
 ctl
   * when the FFCLOCK option is defined.
 diff --git a/sys/sys/time.h b/sys/sys/time.h
 index 8305e9f..ae12db4 100644
 --- a/sys/sys/time.h
 +++ b/sys/sys/time.h
 @@ -313,6 +313,9 @@ void	nanouptime(struct timespec *tsp);
  void	microuptime(struct timeval *tvp);
 =20
  void	bintime(struct bintime *bt);
 +#ifdef KDTRACE_HOOKS
 +void	dtrace_getnanotime(struct timespec *tsp);
 +#endif
  void	nanotime(struct timespec *tsp);
  void	microtime(struct timeval *tvp);
 =20
 --=20
 1.7.10.3
 
 
 --MP_/p0jwU+TkxCvymDAc7Vzdz./--
 
 --Sig_/HLlEY/P2yM4Fc_6RJbVIg93
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAk/1pYYACgkQSMVSH78upWNT0wCfR0gdE7Tu2UW62Q9V7EiuDSFC
 NFMAoIIc7Ts0aDSgKR6jfWzfM/COm6V9
 =+aSl
 -----END PGP SIGNATURE-----
 
 --Sig_/HLlEY/P2yM4Fc_6RJbVIg93--

From: Andriy Gapon <avg@FreeBSD.org>
To: Fabian Keil <fk@fabiankeil.de>
Cc: bug-followup@FreeBSD.org, ashley.wil@gmail.com,
        George Neville-Neil <gnn@FreeBSD.org>
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions incomplete
Date: Thu, 05 Jul 2012 18:15:16 +0300

 on 05/07/2012 17:32 Fabian Keil said the following:
 > Andriy Gapon <avg@FreeBSD.org> wrote:
 > 
 >> on 04/07/2012 19:14 Fabian Keil said the following:
 >>> Andriy Gapon <avg@FreeBSD.org> wrote:
 >>>
 >>>> I am not sure if this synthetic test is a showstopper here, actually.
 >>>> But what about inlining body of getnanotime into dtrace_gethrestime (while perhaps
 >>>> applying some mathematical optimizations) ?
 >>>> I think that that should be possible and should solve the problem at hand.
 >>>
 >>> I don't doubt that it's possible, but there are multiple (get)nanotime()
 >>> implementations and my impression was that it would require quite a bit
 >>> of code duplication.
 >>
 >> Nope. There is only one nanotime and getnanotime and getnanotime is quite small.
 > 
 > fk@r500 ~ $egrep "^(get)?nanotime" /usr/src/sys/kern/kern_tc.c
 > nanotime(struct timespec *tsp)
 > getnanotime(struct timespec *tsp)
 > nanotime(struct timespec *tsp)
 > getnanotime(struct timespec *tsp)
 > 
 > The two getnanotime()s seem to currently boil down to the same
 > code (something I previously missed), but the two nanotime()s don't.
 
 Ah, I didn't notice appearance of FFCLOCK code...
 Not sure how widely it is used, but nevertheless it now has to be taken into account.
 
 >>>> Well, because 'static struct timehands *volatile timehands' is static,
 >>>> dtrace_gethrestime would have to go sys/kern/kern_tc.c under KDTRACE_HOOKS.
 > 
 > The attached patch does that and it's indeed a lot less invasive
 > than I suspected.
 > 
 >>>> Or dtrace_gethrestime would be a wrapper around another "dtrace_"-prefixed
 >>>> function (e.g. dtrace_getnanotime), which would go to sys/kern/kern_tc.c.
 >>>> Alternatively, timehands variable can "unstatisized" / "globalized".
 >>>>
 >>>> Maybe this is worth discussing on hackers@.
 >>>>
 >>>> Also, regarding nanotime() vs getnanotime(), I see that in the latest publicly
 >>>> available version of OpenSolaris code they update time for dtrace_gethrestime()
 >>>> once per tick via dtrace_hres_tick().  So not sure if we should strive to be "more
 >>>> catholic than Pope".
 >>>
 >>> I agree that FreeBSD's walltimestamps don't have to be more accurate
 >>> that on OpenSolaris or illumos, but it's unclear to me what the expected
 >>> accuracy is there.
 >>>
 >>> All the documentation I'm aware of specifies that the value is
 >>> given in nanoseconds, but how often it changes isn't mentioned.
 >>
 >> Once per tick in OpenSolaris as I've said earlier.
 > 
 > Sorry, I meant that I haven't seen the connection documented anywhere.
 > 
 > The walltimestamp description in the DTrace book is:
 > "Nanoseconds since epoch (January 1, 1970)"
 > which seems a bit misleading if the value only gets updated
 > once per tick.
 
 Well, nanoseconds refers only to units.  But indeed there is no word on actual
 precision (or is it accuracy) of the reported time.
 
 >>> I used getnanotime() in an earlier version of the patch and the
 >>> sanity check results were really poor:
 >>>
 >>>   forward                                                        9958
 >>>   no change                                                    387545
 >>>   walltimestamps                                               397501
 > 
 > Replacing syscall:::entry with tick-1msec it looks a lot better, though:
 > 
 > -------------- 2012 Jul  4 23:18:43 --------------
 > walltimestamp:
 > 
 >   no change                                                       101
 >   forward                                                     2147900
 >   total                                                       2148001
 > 
 > timestamp:
 > 
 >   forward                                                     2148001
 >   total                                                       2148001
 > 
 >>> I would expect always calling getnanotime() directly to be even
 >>> less accurate than calling nanotime() once per clock tick (assuming
 >>> kern.hz=1000).
 > 
 > Apparently that's not the case.
 
 Thank you for the patch and testing.
 
 -- 
 Andriy Gapon
 
 

From: George Neville-Neil <gnn@FreeBSD.org>
To: Andriy Gapon <avg@freebsd.org>
Cc: Fabian Keil <fk@fabiankeil.de>,
 bug-followup@FreeBSD.org,
 ashley.wil@gmail.com
Subject: Re: kern/159612: [dtrace] walltimestamp and timestamp functions incomplete
Date: Sun, 8 Jul 2012 22:55:51 -0400

 On Jul 5, 2012, at 11:15 , Andriy Gapon wrote:
 
 > on 05/07/2012 17:32 Fabian Keil said the following:
 >> Andriy Gapon <avg@FreeBSD.org> wrote:
 >>=20
 >>> on 04/07/2012 19:14 Fabian Keil said the following:
 >>>> Andriy Gapon <avg@FreeBSD.org> wrote:
 >>>>=20
 >>>>> I am not sure if this synthetic test is a showstopper here, =
 actually.
 >>>>> But what about inlining body of getnanotime into =
 dtrace_gethrestime (while perhaps
 >>>>> applying some mathematical optimizations) ?
 >>>>> I think that that should be possible and should solve the problem =
 at hand.
 >>>>=20
 >>>> I don't doubt that it's possible, but there are multiple =
 (get)nanotime()
 >>>> implementations and my impression was that it would require quite a =
 bit
 >>>> of code duplication.
 >>>=20
 >>> Nope. There is only one nanotime and getnanotime and getnanotime is =
 quite small.
 >>=20
 >> fk@r500 ~ $egrep "^(get)?nanotime" /usr/src/sys/kern/kern_tc.c
 >> nanotime(struct timespec *tsp)
 >> getnanotime(struct timespec *tsp)
 >> nanotime(struct timespec *tsp)
 >> getnanotime(struct timespec *tsp)
 >>=20
 >> The two getnanotime()s seem to currently boil down to the same
 >> code (something I previously missed), but the two nanotime()s don't.
 >=20
 > Ah, I didn't notice appearance of FFCLOCK code...
 > Not sure how widely it is used, but nevertheless it now has to be =
 taken into account.
 >=20
 >>>>> Well, because 'static struct timehands *volatile timehands' is =
 static,
 >>>>> dtrace_gethrestime would have to go sys/kern/kern_tc.c under =
 KDTRACE_HOOKS.
 >>=20
 >> The attached patch does that and it's indeed a lot less invasive
 >> than I suspected.
 >>=20
 >>>>> Or dtrace_gethrestime would be a wrapper around another =
 "dtrace_"-prefixed
 >>>>> function (e.g. dtrace_getnanotime), which would go to =
 sys/kern/kern_tc.c.
 >>>>> Alternatively, timehands variable can "unstatisized" / =
 "globalized".
 >>>>>=20
 >>>>> Maybe this is worth discussing on hackers@.
 >>>>>=20
 >>>>> Also, regarding nanotime() vs getnanotime(), I see that in the =
 latest publicly
 >>>>> available version of OpenSolaris code they update time for =
 dtrace_gethrestime()
 >>>>> once per tick via dtrace_hres_tick().  So not sure if we should =
 strive to be "more
 >>>>> catholic than Pope".
 >>>>=20
 >>>> I agree that FreeBSD's walltimestamps don't have to be more =
 accurate
 >>>> that on OpenSolaris or illumos, but it's unclear to me what the =
 expected
 >>>> accuracy is there.
 >>>>=20
 >>>> All the documentation I'm aware of specifies that the value is
 >>>> given in nanoseconds, but how often it changes isn't mentioned.
 >>>=20
 >>> Once per tick in OpenSolaris as I've said earlier.
 >>=20
 >> Sorry, I meant that I haven't seen the connection documented =
 anywhere.
 >>=20
 >> The walltimestamp description in the DTrace book is:
 >> "Nanoseconds since epoch (January 1, 1970)"
 >> which seems a bit misleading if the value only gets updated
 >> once per tick.
 >=20
 > Well, nanoseconds refers only to units.  But indeed there is no word =
 on actual
 > precision (or is it accuracy) of the reported time.
 >=20
 >>>> I used getnanotime() in an earlier version of the patch and the
 >>>> sanity check results were really poor:
 >>>>=20
 >>>>  forward                                                        =
 9958
 >>>>  no change                                                    =
 387545
 >>>>  walltimestamps                                               =
 397501
 >>=20
 >> Replacing syscall:::entry with tick-1msec it looks a lot better, =
 though:
 >>=20
 >> -------------- 2012 Jul  4 23:18:43 --------------
 >> walltimestamp:
 >>=20
 >>  no change                                                       101
 >>  forward                                                     2147900
 >>  total                                                       2148001
 >>=20
 >> timestamp:
 >>=20
 >>  forward                                                     2148001
 >>  total                                                       2148001
 >>=20
 >>>> I would expect always calling getnanotime() directly to be even
 >>>> less accurate than calling nanotime() once per clock tick (assuming
 >>>> kern.hz=3D1000).
 >>=20
 >> Apparently that's not the case.
 >=20
 > Thank you for the patch and testing.
 
 I see this has not yet gone into HEAD.  Andriy, do you plan to do that =
 or were you waiting on me?
 
 Best,
 George
 
State-Changed-From-To: open->patched 
State-Changed-By: gnn 
State-Changed-When: Thu Jul 26 18:13:58 UTC 2012 
State-Changed-Why:  
This should be fixed by: 

http://svn.freebsd.org/changeset/base/238537 


http://www.freebsd.org/cgi/query-pr.cgi?pr=159612 
State-Changed-From-To: patched->closed 
State-Changed-By: markj 
State-Changed-When: Sun Dec 29 18:12:07 UTC 2013 
State-Changed-Why:  
This change has been MFCed to stable/9. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=159612 
>Unformatted:
