From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754315AbcHXIVG (ORCPT ); Wed, 24 Aug 2016 04:21:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:54546 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753188AbcHXIVD (ORCPT ); Wed, 24 Aug 2016 04:21:03 -0400 Date: Wed, 24 Aug 2016 09:20:57 +0100 From: Mel Gorman To: Michal Hocko Cc: Joonsoo Kim , Aruna Ramakrishna , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , Christoph Lameter , Pekka Enberg , David Rientjes , Andrew Morton , Jiri Slaby Subject: Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Message-ID: <20160824082057.GT2693@suse.de> References: <1471458050-29622-1-git-send-email-aruna.ramakrishna@oracle.com> <20160818115218.GJ30162@dhcp22.suse.cz> <20160823021303.GB17039@js1304-P5Q-DELUXE> <20160823153807.GN23577@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20160823153807.GN23577@dhcp22.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote: > Do we have any documentation/study about which particular workloads > benefit from which allocator? It seems that most users will use whatever > the default or what their distribution uses. E.g. SLES kernel use SLAB > because this is what we used to have for ages and there was no strong > reason to change that default. Yes, with the downside that a reliance on high-orders contended on the zone lock which would not scale and could degrade over time. If there were multiple compelling reasons then it would have been an easier switch. I did prototype high-order pcp caching up to PAGE_ALLOC_COSTLY_ORDER but it pushed the size of per_cpu_pages over a cache line which could be problematic in itself. I never finished off the work as fixing the allocator for SLUB was not a priority. The prototype no longer applies as it conflicts with the removal of the fair zone allocation policy. If/when I get back to the page allocator, the priority would be a bulk API for faster allocs of batches of order-0 pages instead of allocating a large page and splitting. -- Mel Gorman SUSE Labs