lkml.org 
[lkml]   [2004]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 plugins
On Sat, Aug 28, 2004 at 05:09:28AM -0500, Steve Bergman wrote:
> On Fri, 2004-08-27 at 23:54 -0700, Hans Reiser wrote:
> > >
> > I didn't write this (more precisely, it only vaguely resembles what I
> > wrote in 1996). Are you saying that it reports system time as real
> > time? If yes, then it is an error, we need to go remove a bunch of
> > numbers from our benchmarks, and thanks for finding it.
> >
> > Zam, please comment.
> >
>
> No. I'm saying that on my setup (kernel 2.6.8.1-mm4/perl 5.8.5/bash
> 3.00) the first line returned from running the test is the:
>
> [1]+ Done ...

> line which throws the array indexes off by 1 and I always get 0 for the
> real time and, yes, the real time gets reported as the system time, I
> think. Plus I get a warning about the fact that "Done" is not numeric.
> This is obviously a problem with my particular setup.

Yes. but that real/sys time parsing isn't reliable.

> After bumping the indexes up by 1, I get the correct real time reported
> as "STAT REAL_TIME". And the system time is reported as "STAT
> CPU_TIME".
>
> "STAT CPU_UTIL", however is computed in a completely different way based
> on numbers collected from /proc/stat. If I'm, reading
> linux/Documentation/filesystems/proc.txt correctly, it is trying to
> return the (system time) / (total time). The total time agrees with
> "STAT REAL_TIME". However, the (system time) that it comes up with here
> is always considerably higher than "STAT CPU_TIME".

CPU_UTIL counts other background processes too. The foreground process may just wait
when all work is done by pdflush. I think CPU_UTIL is more useful than CPU_TIME.

>
> User error is quite possible, as I am:
>
> 1. Just getting to know mongo.
> 2. Not a perl guy.

i don't like perl too much, but seems Perl is perfect for the things you just did (the fixes).

> 3. There is obviously something mongo.pl doesn't like about my setup.
>
> -Steve Bergman
>
> P.S. In the 2 tests I've run, reiser4 is not doing all that badly
> against ext3 in OVERWRITE and MODIFY, though ext3 does come in faster.
> Reiser4 trails badly on APPEND however, ext3 (data=ordered, without
> htree) being some 2.5 - 4 times faster.

--
Alex.
-
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 14:05    [W:0.903 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site