From owner-freebsd-current@FreeBSD.ORG Mon Apr 30 21:28:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38CCF16A402; Mon, 30 Apr 2007 21:28:34 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.freebsd.org (Postfix) with ESMTP id 34AEB13C487; Mon, 30 Apr 2007 21:28:32 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep01.bredband.com with ESMTP id <20070430212831.VMRK28445.mxfep01.bredband.com@ironport2.bredband.com>; Mon, 30 Apr 2007 23:28:31 +0200 Received: from c-5416e555.03-51-73746f3.cust.bredbandsbolaget.se (HELO scode.mine.nu) ([85.229.22.84]) by ironport2.bredband.com with ESMTP; 30 Apr 2007 23:28:31 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by scode.mine.nu (Postfix) with ESMTP id 294F51B0A; Mon, 30 Apr 2007 23:28:31 +0200 (CEST) Message-ID: <46365F76.7090708@infidyne.com> Date: Mon, 30 Apr 2007 23:28:22 +0200 From: Peter Schuller User-Agent: Thunderbird 1.5.0.10 (X11/20070417) MIME-Version: 1.0 To: Craig Boston , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> In-Reply-To: <20070410003505.GA8189@nowhere> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF04CD83DED20F6D94E36C095" Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 21:28:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF04CD83DED20F6D94E36C095 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Hi, just wanted to chime in that I'm experiencing the same panic with > a fresh -CURRENT. I am also/still seeing the "kmem_map too small" panic on a tree cvsup:ed around April 27. I can consistently trigger it by doing "rsync -a /usr/ports /somepool/somepath", with both /usr and /somepool being on ZFS (different pools). This is on a machine with 1 GB memory, with the kmem size being 320 MB as per default. The kstat.zfs.misc.arcstats.size never jumps; the "solaris" memory usage never significantly jumps - stays between about 80 MB and 150 MB at all times. It does not even consistently increase in size within this range - it goes up and down. In terms of absolute sizes, nothing in the output of vmstat -m, except solaris, is even approaching the sizes we are talking about (everything is a handful of megs at most). Watching "top" during the rsync I can see wired memory steadily increasing. Starting at about 110 megs or so after startup (including parts of my desktop), it begins consistently increasing when I run the rsync. in this case I started to approach 200 megs. When rsync was done (ran it with -v this time) reading the source directory and began copying files, the growth of wired memory increased significantly in speed (it was up to 280 MB or so in under 30 seconds). Killing rsync did not cause the wired total to go down. Any suggestions on whether there is something else to monitor to find out what is using all the memory? zfs_kmem_alloc() always allocates with M_SOLARIS. kmem_cache_{create,alloc} don't, but they seem to be allocating very small amounts of memory (could there be leakage of a huge number of these?). Is it expected that ZFS would allocate significant amount of memory that is not categorized as M_SOLARIS? Could there be fragmentation going on? Are there very large allocations, relative to the 320 MB kmem size, intermixed with small allocations? Anything I can do in terms of testing that would help debug this, beyond what has already been done and reported on on -current? --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --------------enigF04CD83DED20F6D94E36C095 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNl9+DNor2+l1i30RCCk+AJ9CyO17c6ESWugBGb0aerpN7VtTjACgxkUK wuINyXFIiLUa88294i9S77M= =NDfk -----END PGP SIGNATURE----- --------------enigF04CD83DED20F6D94E36C095--