linux-kernel - Re: [PATCH 2/3] staging: lustre: lnet: Allocate MEs and small MDs in own kmem

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160610163610.GA20291@kroah.com>
Date:	Fri, 10 Jun 2016 09:36:10 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Faccini, Bruno" <bruno.faccini@...el.com>
Cc:	James Simmons <jsimmons@...radead.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"Dilger, Andreas" <andreas.dilger@...el.com>,
	"Drokin, Oleg" <oleg.drokin@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH 2/3] staging: lustre: lnet: Allocate MEs and small MDs in
 own kmem_caches


A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Fri, Jun 10, 2016 at 03:25:28PM +0000, Faccini, Bruno wrote:
> Hello,
> The intent of this patch is not to solve the corruptions for sure, but
> only to avoid the concerned MEs/small-MDs LNet structs to be quite
> frequently impacted due to their high allocation/free rate.

But that's not what the patch description said :(

And again, putting them in a separate cache is not going to save much of
anything, given that your caches might have been merged together anyway.

> This may also possibly help to save cycles due to high usage and
> contention when using a generic kmem_cache (when they stay separate
> from others, thanks for the precision!).

Have you measured this?

This isn't applicable for 4.7-rc at this time, _unless_ it fixes a bug,
which is why I pushed back on this.  If you want your own cache for
these variables, fine, I don't care, but that makes it a 4.8-rc1 patch
instead.

hope that helps explain things better,

greg k-h