From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 16:10:12 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C2E1065675; Wed, 1 Jun 2011 16:10:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 807828FC15; Wed, 1 Jun 2011 16:10:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08418; Wed, 01 Jun 2011 19:10:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE66461.6040202@FreeBSD.org> Date: Wed, 01 Jun 2011 19:10:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Artem Belevich References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> <4DE64D45.5060100@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:10:12 -0000 on 01/06/2011 17:55 Artem Belevich said the following: > On Wed, Jun 1, 2011 at 7:31 AM, Andriy Gapon wrote: >> on 31/05/2011 22:21 Artem Belevich said the following: >>> On Tue, May 31, 2011 at 12:07 PM, David P Discher 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