From owner-freebsd-stable@FreeBSD.ORG Sun Mar 4 08:47:07 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1505616A403 for ; Sun, 4 Mar 2007 08:47:07 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from istc.kiev.ua (wolf.istc.kiev.ua [193.108.236.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDBE13C491 for ; Sun, 4 Mar 2007 08:47:06 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from localhost ([127.0.0.1] helo=ravenloft.kiev.ua) by istc.kiev.ua with esmtp (Exim 4.52) id 1HNmMy-0007UL-FW; Sun, 04 Mar 2007 10:47:04 +0200 Received: from kozlov by ravenloft.kiev.ua with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HNmLw-0000qa-Qx; Sun, 04 Mar 2007 10:46:00 +0200 Date: Sun, 4 Mar 2007 10:46:00 +0200 From: Alex Kozlov To: Yar Tikhiy Message-ID: <20070304084600.GA3152@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Sender: Alex Kozlov X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis detailz: (0.0 points, 10.0 required) Cc: stable@freebsd.org, Mikhail Teterin Subject: Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2007 08:47:07 -0000 On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote: > On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: > > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: > > = > Yes, I switched to swap-backed md already. But the malloc-based variety is > > = > currently the _default_ (see /etc/defaults/rc.conf)... > > = Bad default. > > > > Filing a PR. > > Keep in mind that changing the default can break existing setups. > Such setups are likely to be broken anyway, but... E.g., if we > drop the -M flag, it will break systems with tons of RAM but little > swap using tmpmfs. OTOH, if we add '-o reserve', that will break > systems with a too large but mostly unused tmpmfs. A sort of a loud > announcement will be needed. #sudo swapoff /dev/ad4s2b #swapinfo Device 1K-blocks Used Avail Capacity #mdconfig -d -u 666 && \ mdconfig -a -t swap -s10000M -u 666 && \ bsdlabel -w /dev/md666 auto && \ newfs -U -f 512 -b 4096 -i 512 -m 0 /dev/md666a && \ mkdir /tmp/mdtest && \ mount /dev/md666a /tmp/mdtest $dd if=/dev/zero of=/tmp/mdtest #df /tmp/mdtest Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md666a 3561822 3561622 200 100% /tmp/mdtest #dmesg Mar 4 10:20:35 ravenloft kernel: pid 97529 (firefox-bin), uid 1001, was killed: out of swap space Mar 4 10:20:39 ravenloft kernel: pid 79658 (Xorg), uid 0, was killed: out of swap space Mar 4 10:20:40 ravenloft kernel: pid 519 (thunderbird-bin), uid 1001, was killed: out of swap space Ouch, but this is still better than panic. > By the way, I seem to be the one responsible for the paragraph in > rc.conf(5) advocating -M "for maximum performance and system stability > at low memory conditions". When I wrote it, I thought as follows: > were the system low on memory, additional swap activity due to mfs > would just make the system start thrashing sooner, while malloc'd > mfs would just report ENOSPC. I was unaware of the panic back then. > Perhaps it was a misconception, either. I haven't heard of any real > pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no > good. > > > = > Creation of a 2Gb malloc-based md should've failed on a machine with > > = > 768Mb of RAM, shouldn't it have? > > = Only if you set '-o reserve'. Memory for malloc-based md was allocated > > = dynamically. > > > > But malloc can only allocate from RAM, right? So the amount of RAM is the hard > > limit, which a malloc-based md can not exceed even in theory. This means, > > md-creation should've failed... > > > > In fact, the limit should, of course, be even lower -- and mdmfs should be > > smart enough to substract the sizes of other kernel memory chunks from the > > maximum. > > > > Since even that would still not be a guarantee against running out, the system > > should be able to recover gracefully instead of panicing. Do you agree? > > FWIW, some discussion of the panic is in the audit trail of kern/87255. > Irrespective of tmpmfs defaults, this is a way to panic the system > with stock tools and without doing something totally stupid like > writing junk to /dev/mem. -- Adios