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