Re: [PATCH] staging: lustre: fix GFP_ATOMIC macro usage

From: Dilger, Andreas
Date: Tue Jan 21 2014 - 15:02:44 EST

On 2014/01/17, 8:17 AM, "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx>

>On Fri, Jan 17, 2014 at 05:51:28PM +0300, Dan Carpenter wrote:
>> We will want to get rid of lustre's custom allocator before this gets
>> out of staging.
>> But one feature that the lustre allocator has which is pretty neat is
>> that it lets you debug how much memory the filesystem is using. Is
>> there a standard way to find this information?
>Create your own mempool/slab/whatever_it's_called and look in the
>debugfs or proc files for the allocator usage, depending on the memory
>allocator the kernel is using.
>That's how the rest of the kernel does it, no reason lustre should be
>any different.

The Lustre allocation macros track the memory usage across the whole
not just of a single structure that a mempool/slab/whatever would do.
This is
useful to know for debugging purposes (e.g. user complains about not having
enough RAM for their highly-tuned application, or to check for leaks at

It can also log the alloc/free calls and post-process them to find leaks
easily, or find pieces code that is allocating too much memory that are not
using dedicated slabs. This also works if you encounter a system with a
of allocated memory, enable "free" logging, and then unmount the
The logs will show which structures are being freed (assuming they are not
leaked completely) and point you to whatever is not being shrunk properly.

I don't know if there is any way to track this with regular kmalloc(), and
creating separate slabs for so ever data structure would be ugly. The
/proc/meminfo data doesn't really tell you what is using all the memory,
the size-NNNN slabs give some information, but are used all over the

I'm pretty much resigned to losing all of this functionality, but it
has been very useful for finding problems.

Cheers, Andreas
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at