Date: Sun, 4 Mar 2007 10:46:00 +0200 From: Alex Kozlov <spam@rm-rf.kiev.ua> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: stable@freebsd.org, Mikhail Teterin <mi+kde@aldan.algebra.com> Subject: Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up Message-ID: <20070304084600.GA3152@ravenloft.kiev.ua>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070304084600.GA3152>