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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
