From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU Date: Thu, 3 Sep 2009 08:00:44 -0700 Message-ID: <20090903150044.GB6761@linux.vnet.ibm.com> References: <4A87CE60.4020506@gmail.com> <4A896324.3040104@trash.net> <4A9EEF07.5070800@gmail.com> <4A9F1620.2080105@gmail.com> <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com> <4A9F7283.1090306@gmail.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Dumazet , Pekka Enberg , Zdenek Kabelac , Patrick McHardy , Robin Holt , Linux Kernel Mailing List , Jesper Dangaard Brouer , Linux Netdev List , Netfilter Developers To: Christoph Lameter Return-path: Received: from e7.ny.us.ibm.com ([32.97.182.137]:60348 "EHLO e7.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252AbZICPHC (ORCPT ); Thu, 3 Sep 2009 11:07:02 -0400 Content-Disposition: inline In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: On Thu, Sep 03, 2009 at 12:45:43PM -0500, Christoph Lameter wrote: > On Thu, 3 Sep 2009, Eric Dumazet wrote: > > > on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this > > rcu_barrier() call, unless we want superfast reboot/halt sequences... > > I stilll think that the action to quiesce rcu is something that the caller > of kmem_cache_destroy must take care of. Why? Thanx, Paul > Could you split this into two patches: One that addresses the poison and > another that deals with rcu? >