Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753652AbbBMPsF (ORCPT ); Fri, 13 Feb 2015 10:48:05 -0500 Received: from resqmta-ch2-01v.sys.comcast.net ([69.252.207.33]:35789 "EHLO resqmta-ch2-01v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753608AbbBMPsC (ORCPT ); Fri, 13 Feb 2015 10:48:02 -0500 Date: Fri, 13 Feb 2015 09:47:59 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Joonsoo Kim cc: David Rientjes , akpm@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, penberg@kernel.org, iamjoonsoo@lge.com, Jesper Dangaard Brouer Subject: Re: [PATCH 1/3] Slab infrastructure for array operations In-Reply-To: <20150213023534.GA6592@js1304-P5Q-DELUXE> Message-ID: References: <20150210194804.288708936@linux.com> <20150210194811.787556326@linux.com> <20150213023534.GA6592@js1304-P5Q-DELUXE> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1710 Lines: 33 On Fri, 13 Feb 2015, Joonsoo Kim wrote: > > I also think that this implementation is slub-specific. For example, > in slab case, it is always better to access local cpu cache first than > page allocator since slab doesn't use list to manage free objects and > there is no cache line overhead like as slub. I think that, > in kmem_cache_alloc_array(), just call to allocator-defined > __kmem_cache_alloc_array() is better approach. What do you mean by "better"? Please be specific as to where you would see a difference. And slab definititely manages free objects although differently than slub. SLAB manages per cpu (local) objects, per node partial lists etc. Same as SLUB. The cache line overhead is there but no that big a difference in terms of choosing objects to get first. For a large allocation it is beneficial for both allocators to fist reduce the list of partial allocated slab pages on a node. Going to the local objects first is enticing since these are cache hot but there are only a limited number of these available and there are issues with acquiring a large number of objects. For SLAB the objects dispersed and not spatially local. For SLUB the number of objects is usually much more limited than SLAB (but that is configurable these days via the cpu partial pages). SLUB allocates spatially local objects from one page before moving to the other. This is an advantage. However, it has to traverse a linked list instead of an array (SLAB). -- 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/