Graceful failure instead of panicking in kmem_malloc

[Kris Kennaway]

Joshua Isom wrote:
> 
> 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 at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to 
>> "freebsd-hackers-unsubscribe at 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.

This is kernel memory, not user memory.  There is a fixed-size arena for 
  mallocs in the kernel, and the panic happens when it fills up and no 
free space can be immediately reclaimed.

Kris