Date: Wed, 11 Mar 2009 18:03:30 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
       Andrew Morton <akpm@linux-foundation.org>,
       Pekka Enberg <penberg@cs.helsinki.fi>, Matt Mackall <mpm@selenic.com>,
       Paul Menage <menage@google.com>, Randy Dunlap <randy.dunlap@oracle.com>,
       linux-kernel@vger.kernel.org
Subject: Re: [patch -mm] cpusets: add memory_slab_hardwall flag
Message-ID: <20090312010330.GK7086@linux.vnet.ibm.com>
Reply-To: paulmck@linux.vnet.ibm.com
References: <alpine.DEB.2.00.0903080917460.25207@chino.kir.corp.google.com> <alpine.DEB.1.10.0903091448110.20314@qirst.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.10.0903091448110.20314@qirst.com>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 961
Lines: 24

On Mon, Mar 09, 2009 at 02:50:06PM -0400, Christoph Lameter wrote:
> Again these are fastpath modifications.
> 
> Scanning the partial list for matching nodes is an expensive operation.
> 
> Adding RCU into the fast paths is also another big worry.

Hello, Christoph,

Adding synchronize_rcu() into a fast path would certainly be a problem,
but call_rcu() should be OK.  If the data structure is updated often
(old elements removed and new elements added), then the cache misses
from elements that were removed, went cache-cold, and then were added
again could potentially cause trouble, but read-mostly data structures
should be OK.

Or were you worried about some other aspect of RCU overhead?

							Thanx, Paul
--
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/