Date: Wed, 1 Jun 2011 07:55:53 -0700 From: Artem Belevich <art@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related Message-ID: <BANLkTikPTnEvVfwn26tDdwzAwOGwV0RS1A@mail.gmail.com> In-Reply-To: <4DE64D45.5060100@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikPTnEvVfwn26tDdwzAwOGwV0RS1A>