From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by kanga.kvack.org (Postfix) with ESMTP id 5B7556B0038 for ; Mon, 7 Sep 2015 16:22:14 -0400 (EDT) Received: by igcrk20 with SMTP id rk20so59690003igc.1 for ; Mon, 07 Sep 2015 13:22:14 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com. [2607:f8b0:4001:c05::22f]) by mx.google.com with ESMTPS id ip4si1174935igb.21.2015.09.07.13.22.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 13:22:13 -0700 (PDT) Received: by igbni9 with SMTP id ni9so63363226igb.0 for ; Mon, 07 Sep 2015 13:22:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150907113026.5bb28ca3@redhat.com> References: <20150903005115.GA27804@redhat.com> <20150903060247.GV1933@devil.localdomain> <20150904032607.GX1933@devil.localdomain> <20150907113026.5bb28ca3@redhat.com> Date: Mon, 7 Sep 2015 13:22:13 -0700 Message-ID: Subject: Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3) From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer Cc: Dave Chinner , Mike Snitzer , Christoph Lameter , Pekka Enberg , Andrew Morton , David Rientjes , Joonsoo Kim , "dm-devel@redhat.com" , Alasdair G Kergon , Joe Thornber , Mikulas Patocka , Vivek Goyal , Sami Tolvanen , Viresh Kumar , Heinz Mauelshagen , linux-mm , "netdev@vger.kernel.org" On Mon, Sep 7, 2015 at 2:30 AM, Jesper Dangaard Brouer wrote: > > The slub allocator have a faster "fastpath", if your workload is > fast-reusing within the same per-cpu page-slab, but once the workload > increases you hit the slowpath, and then slab catches up. Slub looks > great in micro-benchmarking. > > And with "slab_nomerge" I get even high performance: I think those two are related. Not merging means that effectively the percpu caches end up being bigger (simply because there are more of them), and so it captures more of the fastpath cases. Obviously the percpu queue size is an easy tunable too, but there are real downsides to that too. I suspect your IP forwarding case isn't so different from some of the microbenchmarks, it just has more outstanding work.. And yes, the slow path (ie not hitting in the percpu cache) of SLUB could hopefully be optimizable too, although maybe the bulk patches are the way to go (and unrelated to this thread - at least part of your bulk patches actually got merged last Friday - they were part of Andrew's patch-bomb). Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org