ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related
Andriy Gapon
avg at FreeBSD.org
Tue May 31 16:56:54 UTC 2011
on 31/05/2011 19:48 Artem Belevich said the following:
> On Tue, May 31, 2011 at 8:24 AM, Andriy Gapon <avg at freebsd.org> wrote:
>>>> 65 nsec = (hrtime_t)ts.tv_sec * NANOSEC + 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=1000000000.
>
> When it's time to use LBOLT, we further multiply number of seconds by HZ:
>>> 41 #define LBOLT ((gethrtime() * hz) / NANOSEC)
>
> In the end we want 64-bit scalar to hold number of seconds times 10e12.
> 0x7fffffffffffffff/1000000000000 = 9223372 # number of seconds before
> signed overflow
> 9223372/(24*60*60) --> 106 # .. or about 106 days
Basically you used that many words to say "yes, I meant overflow in LBOLT"? :-)
Because gethrtime alone would overflow in about 1000 * 100 days (~300 years).
>> To summarize:
>> 1. We must fix ddi_get_lbolt*() to avoid unnecessary overflow in multiplication
>
> Agreed.
Okey.
>> 2. We could fix 31-bit clock_t overflow by using Solaris-compatible definition of
>> it (long), but that still won't help on i386. Maybe we should bring up this issue
>> to the attention of upstream ZFS developers. Universally using ddi_get_lbolt64()
>> seems like a safer bet.
>
> 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.
--
Andriy Gapon
More information about the freebsd-fs
mailing list