Date: Wed, 9 Jan 2008 03:29:43 -0600 From: Joshua Isom <jrisom@gmail.com> To: "Bharma Ji" <bharmaji@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Graceful failure instead of panicking in kmem_malloc Message-ID: <66462bcb31fb347796200bd5260d7cdc@gmail.com> In-Reply-To: <67beabb0801081925t67f995b8hc4cc779f88c2ba@mail.gmail.com> References: <67beabb0801081555v4ca3b729x294322fa724afa09@mail.gmail.com> <4784159E.9040905@FreeBSD.org> <67beabb0801081925t67f995b8hc4cc779f88c2ba@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 8, 2008, at 9:25 PM, Bharma Ji wrote:
> Thanks for the response. I am hoping to keep some memory aside
> specifically
> for handling out of memory allocation situations. Yes the real fix is
> to
> avoid out of memory allocation. Thanks for the patch. Will try that.
> As a
> first cut I am just trying to handle failure gracefully.
>
> So asking again - if there is any way already discussed or
> standardized to
> make the system handle failures gracefully
>
> On Jan 8, 2008 4:30 PM, Kris Kennaway <kris@freebsd.org> wrote:
>
>> Bharma Ji wrote:
>>> In FreeBSD 6_2, if kmem_malloc is unable to find space it panics. The
>>> relevant code is in vm_kern.c
>>> if ((flags & M_NOWAIT) == 0)
>>> panic("kmem_malloc(%ld): kmem_map too small:
>> %ld
>>> total allocated",
>>> (long)size, (long)map->size);
>>>
>>> Is there any way to make the system log and then gracefully shut off
>> instead
>>> of panicking?
>>
>> Not really, because those actions require memory allocation. The real
>> fix is to either
>>
>> a) avoid running out of memory in the first place by tuning
>> vm.kmem_size
>>
>> b) perhaps trying harder to avoid panicking by first trying to more
>> aggressively reclaim memory.
>>
>> You can try
>>
>>
>> http://www.freebsd.org/~pjd/patches/vm_kern.c.2.patch<http://
>> www.freebsd.org/%7Epjd/patches/vm_kern.c.2.patch>
>>
>> which implements b) (patch against 7.0, but might apply to 6.2
>> unchanged).
>>
>> Kris
>>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe@freebsd.org"
Why not try to take out some user processes? Going with a combination
of process priority and memory usage, it should at least be more
tolerable than a panic.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66462bcb31fb347796200bd5260d7cdc>