From owner-freebsd-fs@FreeBSD.ORG Sun Sep 5 20:31:22 2010 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 36B9710656B1 for ; Sun, 5 Sep 2010 20:31:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC548FC0A for ; Sun, 5 Sep 2010 20:31:21 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id 38FN1f0030bG4ec528XMRC; Sun, 05 Sep 2010 20:31:21 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta03.westchester.pa.mail.comcast.net with comcast id 38XL1f00E3LrwQ23P8XMWu; Sun, 05 Sep 2010 20:31:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 291D19B425; Sun, 5 Sep 2010 13:31:19 -0700 (PDT) Date: Sun, 5 Sep 2010 13:31:19 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20100905203119.GA55546@icarus.home.lan> References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk> <4C825D65.3040004@DataIX.net> <7EA7AD058C0143B2BF2471CC121C1687@multiplay.co.uk> <1F64110BFBD5468B8B26879A9D8C94EF@multiplay.co.uk> <4C83A214.1080204@DataIX.net> <06B9D23F202D4DB88D69B7C4507986B7@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06B9D23F202D4DB88D69B7C4507986B7@multiplay.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, jhell Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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: Sun, 05 Sep 2010 20:31:22 -0000 On Sun, Sep 05, 2010 at 09:13:16PM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "jhell" > > >I am not exactly sure what your source is right now but guessing its at > >least 8.1-RELEASE & hoping its 8.1-STABLE. > > > >Line 3656 & 3657 of arc.c ? what are they ? > > > >Do they look like the following, > >3656: uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count > >3657: + cnt.v_cache_count); > > Sorry yes running 8.1-RELEASE with the patches mentioned atm: > > 3656 of arc.c looks like: > > if (arc_size > arc_c_min) { > uint64_t evictable_memory = > arc_mru->arcs_lsize[ARC_BUFC_DATA] + > arc_mru->arcs_lsize[ARC_BUFC_METADATA] + > arc_mfu->arcs_lsize[ARC_BUFC_DATA] + > arc_mfu->arcs_lsize[ARC_BUFC_METADATA]; > available_memory += MIN(evictable_memory, arc_size - arc_c_min); > } > > earlier at 3614 I have what I think your after which is: > uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count); No, that line of code is different than the one jhell provided. Additionally, there are other changes in the same commit which are being overlooked. There have been changes between 8.1-RELEASE and RELENG_8 (8.0-STABLE), some affecting ARC behaviour. Rather than go through "patch hell", staring at hundreds of lines of code and trying to work out what got changed where or hacking up a solution, I'd recommend you simply move to RELENG_8 (8.1-STABLE) and see if the behaviour you describe goes away. If it doesn't improve, patches might be written that address the problem, and those patches will only be for RELENG_8, because that's where all the attention is being applied to. RELENG_8_x (8.x-RELEASE) branches do not get this attention (and this is intentional). There is no official resource/announcement regarding when changes in the FreeBSD ZFS code changes, regardless of branch. Users are apparently "expected" to follow commits/changes as they come in. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |