From owner-freebsd-fs@FreeBSD.ORG Tue May 31 19:07:40 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 A916E1065679; Tue, 31 May 2011 19:07:40 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail1.sjc1.bitgravity.com (mail1.sjc1.bitgravity.com [209.131.97.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8C45C8FC16; Tue, 31 May 2011 19:07:40 +0000 (UTC) Received: from mail-pw0-f45.google.com ([209.85.160.45]) by mail1.sjc1.bitgravity.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QRUI0-000Ewr-7Z; Tue, 31 May 2011 12:07:40 -0700 Received: by pwi6 with SMTP id 6so2768205pwi.18 for ; Tue, 31 May 2011 12:07:34 -0700 (PDT) Received: by 10.142.247.34 with SMTP id u34mr1028412wfh.48.1306868854574; Tue, 31 May 2011 12:07:34 -0700 (PDT) Received: from netops-173.sfo1.bitgravity.com (netops-173.sfo1.bitgravity.com [209.131.110.173]) by mx.google.com with ESMTPS id c5sm260706pbj.57.2011.05.31.12.07.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 12:07:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher In-Reply-To: <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 12:07:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Artem Belevich 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: Tue, 31 May 2011 19:07:40 -0000 On May 31, 2011, at 9:56 AM, Andriy Gapon wrote: >>=20 >> FYI, we've already changed clock_t for opensolaris code to int64_t in >> r218169 regardless of $MACHINE. >=20 > I think that's a good solution. > I hope that we don't have any place where osol clock_t would somehow = mix with fbsd > clock_t with detrimental effects. Well, clock_t to int64_t only fixes l2arc_reclaim_thread. If you look at lines 1712-1725 in = sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict(), = (8.1-release), you'll see that clock_t is not use. So, yes, clock_t = will fix the l2arc issue, but not the arc_reclaim/arc evict issue of the = signed 64bit int overflowing for LBOLT. And from the conversation on this thread, there isn't any agreement on = how to really fix it. Someone please explain to me the units of LBOLT? =20 hz is cycles per second right ? #define LBOLT ((gethrtime() * hz) / NANOSEC) gethrtime() is returning nanoseconds. How is LBOLT in ticks-per-second = ? In sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c : 152 /* number of seconds before growing cache again */ 153 static int arc_grow_retry =3D 60; ... 2255 /* reset the growth delay for every = reclaim */ 2256 growtime =3D LBOLT + (arc_grow_retry * = hz); LBOLT is then clearly using it math with ticks-per-second. I'm I just = crazy ? It seems to me that in this case, line 2256 ... can't be added = together.=20 --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com