From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 17:28:02 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 9C6801065670 for ; Sat, 29 Jan 2011 17:28:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 398F58FC0C for ; Sat, 29 Jan 2011 17:28:01 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0THRueU018966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 04:27:59 +1100 Date: Sun, 30 Jan 2011 04:27:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Matuska In-Reply-To: <4D443407.7010604@FreeBSD.org> Message-ID: <20110130041141.G30713@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-386676537-1296322076=:30713" Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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: Sat, 29 Jan 2011 17:28:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-386676537-1296322076=:30713 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 29 Jan 2011, Martin Matuska wrote: > I agree to you that we have different types and this may be an issue but > I disagree to your patch. > clock_t is not signed (int64_t) and this can be done in a much easier > (and cleaner way) without touching the code, see attached patch. clock_t should be not signed (int32_t), i.e. uint32_t. This is quite broken in FreeBSD, although it was almost correct in 4.4BSD-Lite ( clock_t was always unsigned long there). Now there is the following mess: amd64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ arm/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock()... *= / i386/include/_types.h:typedef=09unsigned long=09__clock_t;=09=09/* clock().= =2E. */ ia64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / mips/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / powerpc/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock().= =2E. */ sparc64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()..= =2E */ sun4v/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ I think the unsignedness 64-bit arches regressed by copying a bug from NetBSD via alpha. NetBSD had to fix hundreds or thousands of longs in old BSD since the size of long is too fuzzy for ABIs once long is actually longer than int (> 32 bits) although still not long (! > register width), and seems to have broken the unsignedness when changing the type. > D=C5=88a 29.01.2011 11:30, Artem Belevich wrote / nap=C3=ADsal(a) >> Hi, >> >> I'm using ZFS v15 on RELENG_8/amd64 box. Some time back I've noticed >> that after a while ZFS starts to consume 100% of CPU time on one of >> the cores. After a bit of digging it appears that the problem is due >> to an integer overflow. >> >> On amd64 (as wel as most other FreeBSD platforms) clock_t is a signed >> 32-bit integer. On OpenSolaris clock_t is long. I don't know how declaring it as long for cddl works when it is not long in FreeBSD. Pehraps because FreeBSD doesn't really use clock_t. Also, long on i386 is just 32 bits, so I don't see how declaring clock_t as long helps in general. Declaring it as uint32_t might delay the overflow from 24.5 days to 49 days. Bruce --0-386676537-1296322076=:30713--