atom feed43 messages in org.freebsd.freebsd-stablepanic: kmem_malloc(16384): kmem_map t...
FromSent OnAttachments
Mikhail TeterinFeb 27, 2007 3:58 pm 
Alex KozlovFeb 27, 2007 5:05 pm 
Mikhail TeterinFeb 27, 2007 7:47 pm 
Alex KozlovFeb 27, 2007 8:54 pm 
Mikhail TeterinFeb 27, 2007 9:03 pm 
Kris KennawayFeb 27, 2007 9:09 pm 
Mikhail TeterinFeb 27, 2007 9:24 pm 
Kris KennawayFeb 27, 2007 9:28 pm 
Kris KennawayFeb 27, 2007 9:51 pm 
Michael ProtoFeb 27, 2007 10:20 pm 
Michael ProtoFeb 27, 2007 10:20 pm 
Yar TikhiyMar 4, 2007 8:27 am 
Alex KozlovMar 4, 2007 8:46 am 
Kris KennawayMar 5, 2007 3:59 am 
Yar TikhiyMar 5, 2007 1:24 pm 
Mikhail TeterinMar 5, 2007 6:40 pm 
Yar TikhiyMar 5, 2007 7:17 pm 
Kostik BelousovMar 5, 2007 8:00 pm 
Yar TikhiyMar 5, 2007 8:13 pm 
Scott LongMar 5, 2007 9:13 pm 
Artem KuchinMar 5, 2007 9:43 pm 
Jack VogelMar 5, 2007 10:21 pm 
Steven HartlandMar 5, 2007 10:26 pm 
Jeremy ChadwickMar 6, 2007 12:07 am 
Charles SprickmanMar 6, 2007 3:14 am 
Artem KuchinMar 6, 2007 8:47 am 
Tom JudgeMar 6, 2007 10:09 am 
Artem KuchinMar 6, 2007 10:53 am 
Tom JudgeMar 6, 2007 11:08 am 
Artem KuchinMar 6, 2007 11:24 am 
Yar TikhiyMar 6, 2007 1:16 pm 
Artem KuchinMar 6, 2007 1:25 pm 
Jack VogelMar 6, 2007 6:04 pm 
Vivek KheraMar 6, 2007 8:16 pm 
Jack VogelMar 6, 2007 9:09 pm 
Torfinn IngolfsenMar 7, 2007 12:16 am 
Danny BranissMar 7, 2007 7:36 am 
Jeremy ChadwickMar 7, 2007 9:24 am 
Jan MikkelsenMar 7, 2007 12:51 pm 
ian j hartMar 7, 2007 9:40 pm 
Jeremy ChadwickMar 7, 2007 10:05 pm 
ian j hartMar 7, 2007 10:50 pm 
ParvMar 12, 2007 10:25 pm 
Subject:panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
From:Yar Tikhiy (ya@comp.chem.msu.su)
Date:Mar 5, 2007 8:13:21 pm
List:org.freebsd.freebsd-stable

On Mon, Mar 05, 2007 at 09:30:22PM +0200, 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 problem isn't that we don't have such a flag yet. It's that some parts of the kernel would rather we didn't have it. :-) Of course, introducing the flag or changing semantics of malloc() in a similar way is a necessary start.