linux-kernel - Re: [PATCH] staging: lustre: fix GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140117151735.GB16623@kroah.com>
Date:	Fri, 17 Jan 2014 07:17:35 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Dan Carpenter <dan.carpenter@...cle.com>
Cc:	devel@...verdev.osuosl.org, Peng Tao <tao.peng@....com>,
	Andreas Dilger <andreas.dilger@...el.com>,
	linux-kernel@...r.kernel.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH] staging: lustre: fix GFP_ATOMIC macro usage

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.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/