All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: kernel stack size
Date: Sun, 03 Apr 2005 09:10:21 +0200	[thread overview]
Message-ID: <424F96DD.2070307@colorfullife.com> (raw)
In-Reply-To: <1112480132.27149.55.camel@localhost.localdomain>

Steven Rostedt wrote:

>>Have you benchmarked your own memory manager?
>>kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386 
>>uniprocessor.
>>    
>>
>
>Where did you get that? I'm looking at the assembly of it right now and
>it's much larger than 17 instructions. Not to mention that it calls the
>slab functions which might have to invoke the buddy system.
>
>  
>
Have you looked at kmem_cache_alloc? kmalloc(1024, GFP_KERNEL) is 
compile-time replaced with the appropriate kmem_cache_alloc call. And 
the fast path within kmem_cache_alloc is 17 instructions long. Best 
case: uniprocessor, no regparams. Unfortunately with cli and popfd, thus 
something like 35 cpu cycles on an Athlon 64.

> I haven't clocked the speed of sem compared to kmalloc.
>But I would think that the sem functions are still quicker.
>
>  
>
Yes - sem or spin locks are quicker as long as no cache line transfers 
are necessary. If the semaphore is accessed by multiple cpus, then 
kmalloc would be faster: slab tries hard to avoid taking global locks. 
I'm not speaking about contention, just the cache line ping pong for 
acquiring a free semaphore.

--
    Manfred

  reply	other threads:[~2005-04-03  7:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-02 20:14 kernel stack size Manfred Spraul
2005-04-02 22:15 ` Steven Rostedt
2005-04-03  7:10   ` Manfred Spraul [this message]
2005-04-03 18:01     ` Steven Rostedt
2005-04-03 19:23       ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2005-04-02 17:46 ooyama eiichi
2005-04-02 17:53 ` Chris Wedgwood
2005-04-02 18:15   ` ooyama eiichi
2005-04-02 18:24     ` Chris Wedgwood
2005-04-02 18:48       ` ooyama eiichi
2005-04-02 19:04         ` Steven Rostedt
2005-04-02 19:37           ` Al Viro
2005-04-02 19:52             ` Steven Rostedt
2005-04-02 18:29     ` Brian Gerst
2003-10-09 19:14 Punj, Arun

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=424F96DD.2070307@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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.