NPTL per char IO locking broken
Just doing some tests with bonnie++ on 2.6.3 with latest glibc in sid
and noticing per char IO is dreadfully slow. Remember a thread months
back about this on LKML: http://kerneltrap.org/node/view/1574
LinuxThreads is almost 4x faster at per char IO.
Here are the relevant benchmarks run just a few minutes ago with
glibc-2.3.2.ds1-11 (using LD_ASSUME_KERNEL=2.4.1 to disable NPTL).
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
2.6.3 NPTL 1G 3313 95 16808 8 5619 3 3291 93 16130 2 74.1 0
2.6.3 LxThreads 1G 11562 92 17384 8 6155 2 11370 81 15846 2 65.1 0
There is a note at the end of the thread (from URL copied below)
about a fix in glibc CVS HEAD. Is this patch in Debian glibc?
Appears to be same problem?
~mc
--
From: Jakub Jelinek [email blocked]
Subject: Re: ext3 performance inconsistencies, 2.4/2.6
Date: Wed, 5 Nov 2003 02:08:32 -0500
On Tue, Nov 04, 2003 at 07:58:16PM -0500, [email blocked] wrote:
> On Tue, Nov 04, 2003 at 03:48:28PM -0800, Ulrich Drepper wrote:
> >
> > The first is the old nptl code, the second LinuxThreads, the third the
> > current nptl code.
>
> By current, do you mean what is in Fedora, or you personal development copy?
Ulrich meant glibc CVS HEAD.
For some reason, stdio locking was not using the jump around lock prefix
variant of locking:
__asm __volatile ("cmpl $0, %%gs:%P6\n\t" \
"je,pt 0f\n\t" \
"lock\n" \
"0:\tcmpxchgl %1, %2\n\t" \
"jnz _L_mutex_lock_%=\n\t" \
".subsection 1\m\t" ...
but one without the first 2 insns, so there were 2 instructions with lock
prefix in putc and similar functions even when only one thread was running.
Jakub
Reply to: