From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750891AbbDFS1P (ORCPT ); Mon, 6 Apr 2015 14:27:15 -0400 Received: from resqmta-ch2-09v.sys.comcast.net ([69.252.207.41]:47440 "EHLO resqmta-ch2-09v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751421AbbDFS1K (ORCPT ); Mon, 6 Apr 2015 14:27:10 -0400 Date: Mon, 6 Apr 2015 13:27:07 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Andrew Morton cc: Jesper Dangaard Brouer , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linuxfoundation.org, Pekka Enberg , iamjoonsoo@lge.com Subject: Re: Slab infrastructure for bulk object allocation and freeing V2 In-Reply-To: <20150402134239.8e8c538103640d697246ba6a@linux-foundation.org> Message-ID: References: <20150331142025.63249f2f0189aee231a6e0c8@linux-foundation.org> <20150402134239.8e8c538103640d697246ba6a@linux-foundation.org> 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 Thu, 2 Apr 2015, Andrew Morton wrote: > hm, OK. The per-allocator wrappers could be made static inline in .h > if that makes sense. The allocators will add code to the "per-allocator wrappers". Inlining that would be bad. Basicalkly the "wrapper" is the skeleon to which optimizations can be added while keeping the call to the generic implementaiton if the allocator has to punt for some reason.