ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related

[Andriy Gapon]

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