From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753158AbcFRDcG (ORCPT ); Fri, 17 Jun 2016 23:32:06 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34782 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751134AbcFRDcE (ORCPT ); Fri, 17 Jun 2016 23:32:04 -0400 Date: Fri, 17 Jun 2016 20:32:03 -0700 From: Greg Kroah-Hartman To: James Simmons Cc: "devel@driverdev.osuosl.org" , "Dilger, Andreas" , Linux Kernel Mailing List , "Drokin, Oleg" , "Faccini, Bruno" , Lustre Development List Subject: Re: [PATCH 2/3] staging: lustre: lnet: Allocate MEs and small MDs in own kmem_caches Message-ID: <20160618033203.GA13004@kroah.com> References: <1465512347-11650-1-git-send-email-jsimmons@infradead.org> <1465512347-11650-3-git-send-email-jsimmons@infradead.org> <20160610012833.GA6804@kroah.com> <20160610163610.GA20291@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 04:02:40AM +0100, James Simmons wrote: > > > > 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, > > As a side question when is the window to push patches of this class? > Is it when 4.7-rc7 is merged to staging? You can send them to me anytime, I'll queue them up in my "-next" branch to be merged in the next merge window. Like I do for almost all lustre patches that aren't bugfixes or regressions. But I think you have a bigger problem here that you need to debug, using a separate cache isn't going to solve that bug, only postpone you finding it... thanks, greg k-h