We recently had an issue with a kernel module leaking memory on unload,
and a userspace app that unloaded it way too many times.
This ended up using up a bunch of memory, which triggered the oom-killer
to run, which went wild killing everything in sight since userspace
wasn't actually the culprt.
One idea we had to prevent this in the future is to configure the OOM
killer to reset the system if the kernel uses more than a certain amount
of memory. (Reset is better than hang for our purposes.) Is there any
way to find out how much memory the kernel is using? I don't see
anything in /proc, but maybe something internal that isn't currently
exported?
Chris
Chris Friesen wrote:
> One idea we had to prevent this in the future is to configure the OOM
> killer to reset the system if the kernel uses more than a certain amount
> of memory. (Reset is better than hang for our purposes.) Is there any
> way to find out how much memory the kernel is using? I don't see
> anything in /proc, but maybe something internal that isn't currently
> exported?
>
How about /proc/slabinfo ?
--
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: [email protected], web: http://www.oktetlabs.ru
Artem B. Bityuckiy wrote:
> Chris Friesen wrote:
>> Is
>> there any way to find out how much memory the kernel is using? I
>> don't see anything in /proc, but maybe something internal that isn't
>> currently exported?
>>
> How about /proc/slabinfo ?
Hmm...if I'm reading that correctly, I should be able to get the total
kernel memory usage by summing up
num_slabs*pagesperslab
for all listed slabs. Does that sound right?
I assume kmalloc/vmalloc use the "size-x" slabs?
Chris
On Wed, 2005-04-27 at 10:57 -0600, Chris Friesen wrote:
> I assume kmalloc/vmalloc use the "size-x" slabs?
kmalloc, yes.
vmalloc is separate, totally unrelated, space.
Statistics are in /proc/meminfo.
Robert Love
Robert Love wrote:
> On Wed, 2005-04-27 at 10:57 -0600, Chris Friesen wrote:
>
>
>>I assume kmalloc/vmalloc use the "size-x" slabs?
>
>
> kmalloc, yes.
>
> vmalloc is separate, totally unrelated, space.
>
> Statistics are in /proc/meminfo.
Okay, so can I get the total amount of memory used by the kernel based
on meminfo output? (Slab + VmallocUsed) maybe?
Chris
On Wed, 2005-04-27 at 11:44 -0600, Chris Friesen wrote:
> Okay, so can I get the total amount of memory used by the kernel based
> on meminfo output? (Slab + VmallocUsed) maybe?
I don't think that will include page tables, unless the architecture
allocates page tables from slab (some might, especially recently).
And it won't have memory that didn't come from slab, e.g.
get_free_pages() or anything else right off the buddy allocator.
There is no easy way to do this. To do it right, we'd need fine-grained
accounting.
Robert Love
On 4/28/05, Chris Friesen <[email protected]> wrote:
>
> We recently had an issue with a kernel module leaking memory on unload,
> and a userspace app that unloaded it way too many times.
>
> This ended up using up a bunch of memory, which triggered the oom-killer
> to run, which went wild killing everything in sight since userspace
> wasn't actually the culprt.
>
> One idea we had to prevent this in the future is to configure the OOM
> killer to reset the system if the kernel uses more than a certain amount
> of memory. (Reset is better than hang for our purposes.) Is there any
Curiously, how to reset? Reboot? (Teach oom killer to kill) or restart
the related
kernel thread?
> way to find out how much memory the kernel is using? I don't see
> anything in /proc, but maybe something internal that isn't currently
> exported?
>
> Chris
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Wed, 27 Apr 2005, Coywolf Qi Hunt wrote:
> On 4/28/05, Chris Friesen <[email protected]> wrote:
>>
>> We recently had an issue with a kernel module leaking memory on unload,
>> and a userspace app that unloaded it way too many times.
>>
>> This ended up using up a bunch of memory, which triggered the oom-killer
>> to run, which went wild killing everything in sight since userspace
>> wasn't actually the culprt.
>>
>> One idea we had to prevent this in the future is to configure the OOM
>> killer to reset the system if the kernel uses more than a certain amount
>> of memory. (Reset is better than hang for our purposes.) Is there any
>
> Curiously, how to reset? Reboot? (Teach oom killer to kill) or restart
> the related
> kernel thread?
>
In user-mode code... `man 2 reboot` tells all.
Quickest way in kernel mode on ix86 is a processor reset.
>
>> way to find out how much memory the kernel is using? I don't see
>> anything in /proc, but maybe something internal that isn't currently
>> exported?
>>
>> Chris
>
In the kernel nr_free_pages() <swap.h> gives you a hint of what's left,
num_physpages() tells you what RAM you started with.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
How about in your private kernel build (Chris),
instrument alloc_pages() and free_pages() to maintain
a simple running tally of GFP_KERNEL and GFP_ATOMIC
page allocation counts ?
I wonder if that would catch all kernel allocations?
Cheers