From: Chris Mason <mason@suse.de>
To: Dimitri Sivanich <sivanich@sgi.com>
Subject: Re: [PATCH] Enable remote RCU callback processing on SMP systems
Date: Wed, 22 Feb 2006 18:56:05 -0500
User-Agent: KMail/1.9.1
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel <linux-kernel@vger.kernel.org>,
       "Paul E. McKenney" <paulmck@us.ibm.com>,
       Dipankar Sarma <dipankar@in.ibm.com>, okir@suse.de
References: <20060206145137.GA30059@sgi.com> <200602221523.23739.mason@suse.de> <20060222220037.GC3734@sgi.com>
In-Reply-To: <20060222220037.GC3734@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602221856.07262.mason@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1225
Lines: 24

On Wednesday 22 February 2006 17:00, Dimitri Sivanich wrote:
> On Wed, Feb 22, 2006 at 03:23:22PM -0500, Chris Mason wrote:
> > Aside from the possible race we talked about in __rcu_process_callbacks,
> > I don't have huge objections here.  But if the underlying problem is the
> > cost of kmem_cache_free, would it be better to limit that instead of
> > trying to push the latency around to specific cpus?
>
> The current problem is the cost of kmem_cache_free.  What this
> patch will do (versus limiting the cost of kmem_cache_free, if
> that's at all possible) is to protect the cpus configured as
> such against other costly sections of code that may be lurking
> or that might be added in the future.

Right, but I'm suggesting that we might want to fix kmem_cache_free as well.  
I think your patch has value even with kmem_cache_free fixed.  Given that the 
high cost parts of kmem_cache_free seem to be numa specific, fixing it seems 
like a good idea in general.

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