Messages in this thread | | | Date | Sun, 03 Apr 2005 09:10:21 +0200 | From | Manfred Spraul <> | Subject | Re: kernel stack size |
| |
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 - 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/
| |