This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc() and spinlocks
- From: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- To: l dot lunak at suse dot cz
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 3 Dec 2002 17:06:40 +0100 ("MET)
- Subject: Re: malloc() and spinlocks
- References: <200211251733.14550.l.lunak@suse.cz> <20021126150223.D1310@sunsite.ms.mff.cuni.cz> <200211261412.PAA22679@max.zk-i.med.uni-muenchen.de> <200212031125.08633.l.lunak@suse.cz>
> I don't care what kind of locking will be there, but webcvs still shows no
> change, so the slow mutexes are still used.
Jakub has raised a valid point, namely that the single-threaded case
is slowed down, albeit very slightly in my opinion.
I've measured:
_single-thread_ malloc-test.c, it=30000000 size=1030, Duron 900MHz
Without spinlocks:
avg. 36.5sec
With spinlocks:
avg. 36.9sec
-> i.e. about 1% slowdown
I'm trying to get this down further, but I think the patch could also
be applied as-is, since the gain for multiple threads is so
tremendous. Surprisingly, text size of libc compiled with
malloc-spinlocks went _down_ slightly.
Regards,
Wolfram.