Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752871AbaBNSkO (ORCPT ); Fri, 14 Feb 2014 13:40:14 -0500 Received: from qmta06.emeryville.ca.mail.comcast.net ([76.96.30.56]:47440 "EHLO qmta06.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbaBNSkA (ORCPT ); Fri, 14 Feb 2014 13:40:00 -0500 Date: Fri, 14 Feb 2014 12:39:58 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@nuc To: Joonsoo Kim cc: Pekka Enberg , Andrew Morton , David Rientjes , Wanpeng Li , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim Subject: Re: [PATCH 4/9] slab: defer slab_destroy in free_block() In-Reply-To: <1392361043-22420-5-git-send-email-iamjoonsoo.kim@lge.com> Message-ID: References: <1392361043-22420-1-git-send-email-iamjoonsoo.kim@lge.com> <1392361043-22420-5-git-send-email-iamjoonsoo.kim@lge.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 Feb 2014, Joonsoo Kim wrote: > In free_block(), if freeing object makes new free slab and number of > free_objects exceeds free_limit, we start to destroy this new free slab > with holding the kmem_cache node lock. Holding the lock is useless and, > generally, holding a lock as least as possible is good thing. I never > measure performance effect of this, but we'd be better not to hold the lock > as much as possible. This is also good because kmem_cache_free is no longer called while holding the node lock. So we avoid one case of recursion. Acked-by: Christoph Lameter -- 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/