All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [rfc][patch] SLQB slab allocator
Date: Fri, 12 Dec 2008 09:05:49 +0100	[thread overview]
Message-ID: <49421B5D.7060207@cosmosbay.com> (raw)
In-Reply-To: <20081212072355.GG15804@wotan.suse.de>

Nick Piggin a écrit :
> On Fri, Dec 12, 2008 at 08:07:23AM +0100, Eric Dumazet wrote:
>> Nick Piggin a écrit :
>>> Is SLAB still bad at the test with the slab-rcu patch in place?
>>> SLAB has a pretty optimal fastpath as well, although if its queues
>>> start overflowing, it can run into contention quite easily.
>> Yes, I forgot I applied Christoph patch (SLAB_DESTROY_BY_RCU for struct file) 
>> in the meantime, silly me, this was with the v2 of my serie, with only 5 patches.
>>
>> With SLAB, results are quite good !
>>
>> # time ./socketallocbench
>>
>> real    0m1.201s
>> user    0m0.071s
>> sys     0m1.122s
>> # time ./socketallocbench -n8
>>
>> real    0m1.616s
>> user    0m0.578s
>> sys     0m12.220s
> 
> Yeah, SLAB is actually very hard to beat, much of the time.
> 
> 
>>>> c0281e10 <kmem_cache_alloc>: /* kmem_cache_alloc total: 140659 10.8277 */
>>> I guess you're compiling with -Os? I find gcc can pack the fastpath
>>> much better with -O2, and actually decrease the effective icache
>>> footprint size even if the total text size increases...
>> No, I dont use -Os, unless something got wrong
>>
>> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
>> # CONFIG_OPTIMIZE_INLINING is not set
> 
> Oh OK. Hmm, you do have SLQB debugging compiled in by the looks. I
> haven't really been looking at code generation in that case. I don't
> expect that would cause a significant difference in your case,
> though.
> 

One thing that might give a difference is to not use kmem_cache_zalloc()
in get_empty_filp(), because on 32bits, sizeof(struct file)=132

So kmem_cache_zalloc() clears 192 bytes, while if done by a memset()
inside get_empty_filp(), we would clear 132 bytes exactly.

OK, I tried without SLQB debugging and got :

# time ./socketallocbench

real    0m1.261s
user    0m0.078s
sys     0m1.183s
# time ./socketallocbench -n 8

real    0m1.640s
user    0m0.638s
sys     0m12.346s


> Anyway, I'll see if I can work out why SLQB is slower. Do you have
> socketallocbench online?


Well, it's so trivial, you probably can code it in perl or whatever in 4 lines :)

its a basic

	for (i = 0; i < 1000000; i++)
		close(socket(AF_INET, SOCK_STREAM, 0));

and -n 8 starts 8 processes doing this same loop in //


  reply	other threads:[~2008-12-12  8:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-12  0:25 [rfc][patch] SLQB slab allocator Nick Piggin
2008-12-12  0:31 ` [rfc][patch] mm: kfree_size Nick Piggin
2008-12-13  2:36   ` Christoph Lameter
2008-12-12  5:38 ` [rfc][patch] SLQB slab allocator Eric Dumazet
2008-12-12  5:50   ` Nick Piggin
2008-12-12  7:07     ` Eric Dumazet
2008-12-12  7:23       ` Nick Piggin
2008-12-12  8:05         ` Eric Dumazet [this message]
2008-12-12  9:43         ` Nick Piggin
2008-12-13  2:34 ` Christoph Lameter
2008-12-13  9:03   ` Pekka Enberg
2008-12-15  1:51     ` Christoph Lameter
2008-12-15  1:51       ` Christoph Lameter
2008-12-14 23:04   ` Nick Piggin
2008-12-14 23:04     ` Nick Piggin
2008-12-15 14:02     ` Christoph Lameter
2008-12-15 14:02       ` Christoph Lameter
2008-12-15 14:16       ` Nick Piggin
2008-12-15 14:16         ` Nick Piggin
2008-12-15 15:03         ` Christoph Lameter
2008-12-15 15:03           ` Christoph Lameter
2008-12-15 23:42 ` MinChan Kim
2008-12-15 23:42   ` MinChan Kim
2008-12-17  6:42   ` Nick Piggin
2008-12-17  6:42     ` Nick Piggin
2008-12-17  7:01     ` MinChan Kim
2008-12-17  7:01       ` MinChan Kim
2008-12-17  7:09       ` Nick Piggin
2008-12-17  7:09         ` Nick Piggin
2008-12-19  7:48 ` Zhang, Yanmin
2008-12-19  7:48   ` Zhang, Yanmin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49421B5D.7060207@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.