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/...

Davide Italiano davide at freebsd.org
Tue Sep 10 12:03:06 UTC 2013


On Tue, Sep 10, 2013 at 3:46 AM, Xin LI <delphij at 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


More information about the svn-src-all mailing list