lkml.org 
[lkml]   [2003]   [Nov]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 4 Nov 2003 13:40:51 -0800 (PST)
FromLinus Torvalds <>
SubjectRe: ext3 performance inconsistencies, 2.4/2.6
On Tue, 4 Nov 2003, Bill Rugolsky Jr. wrote:
> 
> Well, I'm too lazy to wait for a long test, but with a mere
> 100MB file, on 1GHz P3:
> 
> Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> NPTL          100M  7735  99 127068  98 63048  84  7890  98 +++++ +++ +++++ +++
> LinuxThreads  100M 11000  99 127928  97 59075  84 11290  98 +++++ +++ +++++ +++
> 
> So something is amiss.

Ok, so NPTL locking (even in the absense of any threads and thus any 
contention) seems to be noticeably higher-overhead than the old 
LinuxThreads. 

90% of the overhead of a putc()/getc() implementation these days is likely
just locking. Even so, this implies that NPTL locking is about twice as 
expensive as the old LinuxThreads one.

Don't ask me why. But I'm cc'ing Uli, who can probably tell us. Maybe the 
RH-9 libraries are just not very good, and LinuxThreads has had a lot 
longer to optimize their lock behaviour..

			Linus


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2008