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

Artem Belevich art at freebsd.org
Wed Jun 1 14:55:54 UTC 2011


On Wed, Jun 1, 2011 at 7:31 AM, Andriy Gapon <avg at freebsd.org> wrote:
> on 31/05/2011 22:21 Artem Belevich said the following:
>> On Tue, May 31, 2011 at 12:07 PM, David P Discher <dpd at bitgravity.com> wrote:
>>> And from the conversation on this thread, there isn't any agreement on how to really fix it.
>> Andriy has proposed potential fix that would eliminate multiplication
>> of gethrtime result by hz and would delay overflow by few hundred
>> years. Should be good enough.
>
> Yeah, and here is a patch that implements the proposal (for head):
> http://people.freebsd.org/~avg/osol-lbolt.diff

I would keep nsec_per_tick as a static local variable in
ddi_get_lbolt64 and init it conditionally if it's zero for the sake of
keeping all the magic in once place.

I have a hypothetical question. In a non-tickless kernel there is a
natural limit on hz imposed by overhead of processing periodis
interrupts.
Now that we're event-driven, is there any chance that hz could grow
larger than 1000000?

--Artem


More information about the freebsd-fs mailing list