Date: Wed, 01 Jun 2011 19:10:09 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Artem Belevich <art@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related Message-ID: <4DE66461.6040202@FreeBSD.org> In-Reply-To: <BANLkTikPTnEvVfwn26tDdwzAwOGwV0RS1A@mail.gmail.com> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <BANLkTikVq0-En7=4Dy_dTf=tM55Cqou_mw@mail.gmail.com> <4DE50811.5060606@FreeBSD.org> <BANLkTinQkS36SQKpZhsavx3C_ad838DG=g@mail.gmail.com> <4DE51DD3.6040602@FreeBSD.org> <C48BAB2B-5667-458D-86A1-8B48C4189560@bitgravity.com> <BANLkTikO9J6NhCZi9K2YdftmjC75LhdO3A@mail.gmail.com> <4DE64D45.5060100@FreeBSD.org> <BANLkTikPTnEvVfwn26tDdwzAwOGwV0RS1A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 01/06/2011 17:55 Artem Belevich said the following: > On Wed, Jun 1, 2011 at 7:31 AM, Andriy Gapon <avg@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@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 don't like having a static variable in a static inline function (used over many files even). > 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, 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE66461.6040202>