Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755191AbYK0Op5 (ORCPT ); Thu, 27 Nov 2008 09:45:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752502AbYK0Opp (ORCPT ); Thu, 27 Nov 2008 09:45:45 -0500 Received: from nlpi053.sbcis.sbc.com ([207.115.36.82]:49928 "EHLO nlpi053.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238AbYK0Opo (ORCPT ); Thu, 27 Nov 2008 09:45:44 -0500 Date: Thu, 27 Nov 2008 08:44:41 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@quilx.com To: Eric Dumazet cc: Ingo Molnar , David Miller , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org, Mike Galbraith , Peter Zijlstra , Linux Netdev List , Christoph Hellwig , Pekka Enberg Subject: Re: [PATCH 0/6] fs: Scalability of sockets/pipes allocation/deallocation on SMP In-Reply-To: <492E3DEF.8030602@cosmosbay.com> Message-ID: References: <20081121083044.GL16242@elte.hu> <49267694.1030506@cosmosbay.com> <20081121.010508.40225532.davem@davemloft.net> <4926AEDB.10007@cosmosbay.com> <4926D022.5060008@cosmosbay.com> <20081121152148.GA20388@elte.hu> <4926D39D.9050603@cosmosbay.com> <20081121153453.GA23713@elte.hu> <492DDB6A.8090806@cosmosbay.com> <492E3DEF.8030602@cosmosbay.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1060 Lines: 37 On Thu, 27 Nov 2008, Eric Dumazet wrote: > with slub_min_objects=45 : > > # cat /sys/kernel/slab/filp/order > 2 > # time ./socket8 > real 0m1.652s > user 0m0.694s > sys 0m12.367s That may be a good value. How many processor do you have? Look at calculate_order() in mm/slub.c: if (!min_objects) min_objects = 4 * (fls(nr_cpu_ids) + 1); We couild increase the scaling factor there or start with a mininum of 20 objects? Try min_objects = 20 + 4 * (fls(nr_cpu_ids) + 1); > I would say slub_min_objects=45 is the optimal value on 32bit arches to > get acceptable performance on this workload (order=2 for filp kmem_cache) > > Note : SLAB here is disastrous, but you already knew that :) Its good though to have examples where the queue management gets in the way of performance. -- 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/