ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related
avg at FreeBSD.org
Wed Jun 1 16:10:12 UTC 2011
on 01/06/2011 17:55 Artem Belevich said the following:
> 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):
> 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 don't like having a static variable in a static inline function (used over many
> I have a hypothetical question. In a non-tickless kernel there is a
> natural limit on hz imposed by overhead of processing periodis
> Now that we're event-driven,
We are not completely there yet, I think.
> is there any chance that hz could grow
> larger than 1000000?
In a completely event driven system hz just doesn't make any sense.
It can be provided for transitioning some old code, which still goes back and
forth between ticks and actual time. In that case one can probably set hz to
almost an arbitrary value, but I don't see what could be gained with increasing
it. But I see where it can hurt :)
In other words, I won't be bothered to worry about this now.
More information about the freebsd-fs