Date: Tue, 31 May 2011 11:41:27 -0700 From: Artem Belevich <art@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related Message-ID: <BANLkTi=J=kQZiOTnBkrrf0Qpj30LqsO7Uw@mail.gmail.com> In-Reply-To: <4DE51DD3.6040602@FreeBSD.org> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <BANLkTikVq0-En7=4Dy_dTf=tM55Cqou_mw@mail.gmail.com> <4DE50811.5060606@FreeBSD.org> <BANLkTinQkS36SQKpZhsavx3C_ad838DG=g@mail.gmail.com> <4DE51DD3.6040602@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 31, 2011 at 9:56 AM, Andriy Gapon <avg@freebsd.org> wrote: > on 31/05/2011 19:48 Artem Belevich said the following: >> On Tue, May 31, 2011 at 8:24 AM, Andriy Gapon <avg@freebsd.org> wrote: >>>>> =A0 =A0 =A0 =A0 65 =A0 =A0 =A0 =A0 nsec =3D (hrtime_t)ts.tv_sec * NAN= OSEC + ts.tv_nsec; >>>> >>>> Yup. This would indeed overflow in ~106.75 days. >>> >>> Have you referred to the LBOLT above? >>> gethrtime() should have several hundred years before overflowing. >> >> hrtime_t is 64-bit. NANOSEC=3D1000000000. >> >> When it's time to use LBOLT, we further multiply number of seconds by HZ= : >>>> =A0 =A0 =A0 =A0 41 #define LBOLT =A0 ((gethrtime() * hz) / NANOSEC) >> >> In the end we want 64-bit scalar to hold number of seconds times 10e12. >> 0x7fffffffffffffff/1000000000000 =3D 9223372 =A0# number of seconds befo= re >> signed overflow >> 9223372/(24*60*60) --> 106 =A0 # .. or about 106 days > > Basically you used that many words to say "yes, I meant overflow in LBOLT= "? :-) Yes. It took a lot of willpower on my part to limit my yes to just few lines. I've got three-volume draft variant if you're interested. :-) >> FYI, we've already changed clock_t for opensolaris code to int64_t in >> r218169 regardless of $MACHINE. > > I think that's a good solution. > I hope that we don't have any place where osol clock_t would somehow mix = with fbsd > clock_t with detrimental effects. That is a potential source of trouble and the point had been raised when r218169 was discussed before commit. At the moment of commit there were only few places in cddl code that used clock_t and those were for internal use only. That was pre-ZFSv28 commit, though. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=J=kQZiOTnBkrrf0Qpj30LqsO7Uw>