Date: Tue, 10 Sep 2013 14:03:04 +0200 From: Davide Italiano <davide@freebsd.org> To: Xin LI <delphij@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r255437 - in head: cddl/contrib/opensolaris/lib/libzpool/common cddl/contrib/opensolaris/lib/libzpool/common/sys sys/cddl/compat/opensolaris/sys sys/cddl/contrib/opensolaris/uts/common/... Message-ID: <CACYV=-EfAH583bY1rkXkskefvRS_4n9VBtG6KLw0mdJvpiWSTQ@mail.gmail.com> In-Reply-To: <201309100146.r8A1kmri091170@svn.freebsd.org> References: <201309100146.r8A1kmri091170@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 10, 2013 at 3:46 AM, Xin LI <delphij@freebsd.org> wrote:
[snip]
> +static clock_t
> +cv_timedwait_hires(kcondvar_t *cvp, kmutex_t *mp, hrtime_t tim, hrtime_t res,
> + int flag)
> +{
> + sbintime_t sbt;
> + sbintime_t pr;
> +
> + sbt = tim * SBT_1NS;
> + pr = res * SBT_1NS;
> +
> + return (cv_timedwait_sbt(cvp, mp, sbt, pr, 0));
> +}
> +
> #endif /* _KERNEL */
>
The Illumos cv_timedwait_hires() doesn't use 'res' argument so if you
want to be consistent with their behaviour you should pass '0' as
precision argument to cv_timedwait_sbt(). Also, I'm not sure there's
an 1:1 mapping between ours 'pr' and their 'res'. Even if there is,
considering you're dealing with nanoseconds I don't think you will see
great advantage from specifying precision argument in most of the
cases (hardware clock resolution is in the common case 10^-6).
> @@ -1473,7 +1473,7 @@ dsl_scan_sync(dsl_pool_t *dp, dmu_tx_t *
> "free_bpobj/bptree txg %llu",
> (longlong_t)scn->scn_visited_this_txg,
> (longlong_t)
> - (gethrtime() - scn->scn_sync_start_time) / MICROSEC,
> + NSEC2MSEC(gethrtime() - scn->scn_sync_start_time),
> (longlong_t)tx->tx_txg);
> scn->scn_visited_this_txg = 0;
> /*
The usage of gethrtime() as-it-is in FreeBSD goes against your
precision requirements. In fact, it's implemented as a wrapper to
getnanouptime(), which could be defined as "fast but not precise" as
it read a cached value which is upadted from time to time rather than
going into the underlying hardware to get the information required.
More precisely speaking, in case hz=1000, you might be 1 millisecond
away from the value you're looking for.
--
Davide
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-EfAH583bY1rkXkskefvRS_4n9VBtG6KLw0mdJvpiWSTQ>