Date: Tue, 25 Sep 2007 11:01:27 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Darren Reed <darrenr@freebsd.org> Cc: freebsd-current@freebsd.org, Larry Rosenman <ler@lerctr.org> Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) Message-ID: <46F8CE67.60206@FreeBSD.org> In-Reply-To: <46F8951C.50904@freebsd.org> References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> <20070921140550.D96923@thebighonker.lerctr.org> <46F41CFF.6080108@FreeBSD.org> <46F58799.1030702@freebsd.org> <46F58B21.8030307@FreeBSD.org> <20070924091558.GB32006@team.vega.ru> <46F78C59.1020801@FreeBSD.org> <20070924080347.O84223@thebighonker.lerctr.org> <20070924144210.GA82735@team.vega.ru> <46F7D7A4.5090007@samsco.org> <46F80A39.3050707@FreeBSD.org> <46F8951C.50904@freebsd.org>
index | next in thread | previous in thread | raw e-mail
Darren Reed wrote: > Kris Kennaway wrote: >> ... >> Well yes, that is one hypothesis, but the evidence points elsewhere as >> well. Prior the change you reference, some of my zfs machines would >> run for weeks before hitting a load pattern that exhausted their >> kmem_map and triggered the panic. Also unless I have missed it I am >> not seeing the sudden flood of panic reports that may indicate sudden >> breakage. It is quite possible that this particular report has >> nothing to do with the recent change. > > Indeed. > > But here's something else to ponder... > > I've been using ZFS since it was internal beta at Sun, at first on i386 > and later on amd64. > I've never run into this kind of panic on Solaris. System can get very > slow, yes, with > ZFS hogging lots of memory, but it never panic'd because of it. > > We need to come up with a strategy here to solve this problem, be it > fixing the kmem > virtual memory or fixing zfs. Yes, Solaris does something architecturally different because it is apparently acceptable for zfs to use gigabytes of memory by default. Krishome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F8CE67.60206>