Date: Mon, 05 Mar 2007 13:37:37 -0700 From: Scott Long <scottl@samsco.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: Yar Tikhiy <yar@comp.chem.msu.su>, stable@freebsd.org Subject: Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up Message-ID: <45EC7F91.5070106@samsco.org> In-Reply-To: <20070305193022.GM10453@deviant.kiev.zoral.com.ua> References: <20070227205351.GA72597@ravenloft.kiev.ua> <20070305035945.GA71660@xor.obsecurity.org> <20070305132350.GB57253@comp.chem.msu.su> <200703051314.29902@aldan> <20070305191714.GF57253@comp.chem.msu.su> <20070305193022.GM10453@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote: > On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote: >> On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: >>> On Monday 05 March 2007 08:23, Yar Tikhiy wrote: >>> = > How will it break them? swap backing only touches swap if there is >>> = > memory pressure, i.e. precisely the situation in which malloc backing >>> = > will panic. >>> = >>> = I forgot that in BSD swap wouldn't be allocated in advance to its >>> = consumers. Then removing the -M flag and making swap backing the >>> = default is a very sound choice. Thank you for correcting me. >>> >>> Yar, would you change the man-page's advice and the default, then? >> Yes, I'll be glad to if no objections arise until I finish updating >> my CURRENT machine, i.e., tomorrow. :-) >> >>> Someone still needs to look into the panic... Who would that be? >> Obviously, Mr(s). Someone. :-) >> >> The md case exposes a quite tangled nature of the problem. Funnily >> enough, kernel malloc() cannot just fail in the case because it >> must not fail if called with M_WAITOK. This means that the system >> has quite a rough choice: >> >> - put the requesting thread to sleep forever; >> - grow kmem_map, eventually sacrifice all RAM to the greedy thread >> and die sooner or later; >> - panic immediately. >> >> If all malloc() callers in the kernel were ready to deal with >> allocation failure, the system could just tell the greedy thread >> to buzz off. But too many kernel parts depend on malloc(M_WAITOK) >> never failing. Perhaps it's the root of the problem. > > Mark callers that are ready for M_WAITOK failure with some additional > flag, like M_FAILOK (feel free to propose meaningful name there). > At least malloc()-based md could then use it. The panic is a chronic problem that really needs to be fixed in general. However, the md code should probably be modified to reject any malloc-backed size larger than some trivial (and arbitrary) value, like say 1MB. It's really inferior to being swap-backed, and it only encourages foot-shooting and these unclear panics. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45EC7F91.5070106>