[prev in list] [next in list] [prev in thread] [next in thread]
List: reiserfs-devel
Subject: (reiserfs) Vladimir gets to the bottom of [Fwd: (reiserfs) Is this bad?]
From: Hans Reiser <reiser () idiom ! com>
Date: 1999-02-08 19:16:45
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I am going to put this into our paper as a concrete example of the possible effects \
of changing our tuning defines. Our project for the future is to get this performance \
without these defines being set, and we are currently exploring changing our key \
allocation algorithm so that we get much of the effect of notails being set. Having \
notails set should ideally only affect memory bandwidth consumption during writes, \
but we currently see a strong effect on reads.
We are also changing file_read so that we get the effect of simple read or complex \
read according to which of them is most optimal. Actually, we are completing \
rewriting file_read, and then we will benchmark against both settings and see if we \
beat them both at both large reads and small reads. We know that we can do something \
stupid involving looking at the size of the read and branching to different code \
accordingly, but we hope for better. Currently complex read is best at large reads, \
and reads with lots of locality of reference.
Hans
--
Dump NT! Get Linux (http://www.kernel.org) plus ReiserFS
(http://devlinux.org/namesys). If you sell an OS or
internet appliance, buy a port of ReiserFS!
Speed matters. Trees are fast. Go faster!
[Attachment #5 (text/html)]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I am going to put this into our paper as a concrete example of the possible
effects of changing our tuning defines.
<br>Our project for the future is to get this performance without these
defines being set,
<br>and we are currently exploring changing our key allocation algorithm
so that we get much of the effect of notails being set.
<br>Having notails set should ideally only affect memory bandwidth consumption
during writes, but we currently see a strong
<br>effect on reads.
<br>We are also changing file_read so that we get the effect of simple
read or complex read according to which of
<br>them is most optimal. Actually, we are completing rewriting file_read,
and then we will benchmark against both
<br>settings and see if we beat them both at both large reads and small
reads. We know that we can do something
<br>stupid involving looking at the size of the read and branching to different
code accordingly, but we hope for better.
<br>Currently complex read is best at large reads, and reads with lots
of locality of reference.
<p>Hans
<pre>--
Dump NT! Get Linux (<A HREF="http://www.kernel.org">http://www.kernel.org</A>) plus ReiserFS
(<A HREF="http://devlinux.org/namesys">http://devlinux.org/namesys</A>). If you sell an OS or
internet appliance, buy a port of ReiserFS!
Speed matters. Trees are fast. Go faster!</pre>
</html>
Return-Path: vs@namesys.botik.ru
Received: from digger.botik.ru (root@digger.botik.ru [195.208.225.248])
by idiom.com (8.8.8/8.8.5) with ESMTP id HAA09567
for <reiser@idiom.com>; Mon, 8 Feb 1999 07:13:19 -0800 (PST)
Received: from namesys.botik.ru (really [127.0.0.1]) by digger.botik.ru
via in.smtpd with esmtp (ident vs using rfc1413)
id <m109sN2-000WQdC@digger.botik.ru> (Debian Smail3.2.0.101)
for <reiser@idiom.com>; Mon, 8 Feb 1999 18:13:08 +0300 (EET)
Sender: vs@namesys.botik.ru
Message-ID: <36BEFEFA.D1E4F007@namesys.botik.ru>
Date: Mon, 08 Feb 1999 18:12:58 +0300
From: "Vladimir V. Saveliev" <vs@namesys.botik.ru>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.2.1 i686)
MIME-Version: 1.0
To: Shawn Leas <sleas@ixion.honeywell.com>, Hans Reiser <reiser@idiom.com>
Subject: Re: (reiserfs) Is this bad?
References: <Pine.GHP.4.05.9902071805350.29194-100000@ixion.honeywell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mozilla-Status2: 00000000
Shawn Leas wrote:
> I just did a quick measure, and want an opinion: Where is
> the bottleneck?
>
> EXT2: tar zxvf glibc-2.1.tar.gz 6.80s user 5.21s system 48% cpu 24.542 total
> REISER: tar zxvf glibc-2.1.tar.gz 7.55s user 10.09s system 28% cpu 1:01.90 total
>
> -Shawn
> <=========== America Held Hostage ===========>
> Day 2209 for the poor and the middle class.
> Day 2228 for the rich and the dead.
> 713 days remaining in the Raw Deal.
> <============================================>
Hello
There are few variants of reiserfs. We still did not decide what of them is the main \
one. In this test, default configuration of reiserfs works bad.
I have changed your test a little:
i=0
while [ $i -lt 10 ]
do
mkdir $i
cd $i
time tar zxf ../glibc_2.0.7t.orig.tar.gz
cd ..
i=$[ $i + 1 ]
done
and repeated it for the configuration that is the fastest one. It is not the default \
because we did not finish our experiments yet.
I uncommented #define SIMPLE_READ in include/linux/reiserfs_fs.h,
formatted with 1K block (mkreiserfs -k 1 /dev/...),
mounted with (mount -t reiserfs -o notail,nopreserve /dev/... /mnt).
Here is the result (elapsed times only):
ext2fs(1k) reiserfs
1. 0:07.02 0:06.17
2. 0:10.21 0:06.13
3. 0:07.57 0:07.27
4. 0:08.57 0:07.67
5. 0:07.59 0:06.68
6. 0:09.32 0:06.39
7. 0:08.76 0:06.25
8. 0:09.10 0:08.40
9. 0:08.24 0:09.76
10. 0:09.10 0:09.87
Thanks
vs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic