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

[Artem Belevich]

On Tue, May 31, 2011 at 9:56 AM, Andriy Gapon <avg at 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 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"? :-)

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