All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: "Jose R. Santos" <jrs@us.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: compilebench numbers for ext4
Date: Thu, 25 Oct 2007 19:45:44 -0400	[thread overview]
Message-ID: <20071025194544.25c6dd7f@think.oraclecorp.com> (raw)
In-Reply-To: <20071025174025.1c042424@gara>

On Thu, 25 Oct 2007 17:40:25 -0500
"Jose R. Santos" <jrs@us.ibm.com> wrote:

> > > 
> > > I really want to use seekwatcher to test some of the stuff that
> > > I'm doing for flex_bg feature but it barfs on me in my test
> > > machine.
> > > 
> > > running :sleep 10:
> > > done running sleep 10
> > > Device: /dev/sdh
> > >   Total:                     0 events (dropped 0),     1368 KiB
> > > data blktrace done
> > > Traceback (most recent call last):
> > >   File "/usr/bin/seekwatcher", line 534, in ?
> > >     add_range(hist, step, start, size)
> > >   File "/usr/bin/seekwatcher", line 522, in add_range
> > >     val = hist[slot]
> > > IndexError: list index out of range
> > 
> > I don't think you have any events in the trace.  Try this instead:
> > 
> > echo 3 > /proc/sys/vm/drop_caches
> > seekwatcher -t find-trace -d /dev/xxxx -p 'find /usr/local -type f'
> 
> Nope, get the same error.  There does seem to be data recorded in the
> trace files and iostat does show activity on the disk.

Hmmm, could you please send me your trace files.  There will be one for
each cpu, starting with find-trace-blktrace

> > I wanted to benchmark flexbg too, but couldn't quite figure out the
> > correct patch combination ;)
> 
> Ill attach e2progfs and Kernel patches but do realize that these are
> experimental patches that Im using to test what layout would work
> best.  Don't take them too seriously as it is largely incomplete.

Thanks, I'll try this out.

> 
> Currently trying to come up with workloads to test this and other
> changes with.  Im am warming up to yours :)

At least for the write phases of compilebench, it should benefit from
data and metadata separation.  It made a very big difference in btrfs,
(from 20MB/s up to 32MB/s on create).  However it did make the read
phases slower.

-chris

  reply	other threads:[~2007-10-25 23:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22 23:31 compilebench numbers for ext4 Chris Mason
2007-10-22 23:48 ` Chris Mason
2007-10-23  0:12 ` Mingming Cao
2007-10-23  0:54   ` Chris Mason
2007-10-23 12:43 ` Aneesh Kumar K.V
2007-10-23 13:08   ` Chris Mason
2007-10-23 13:42     ` Aneesh Kumar K.V
2007-10-25 15:34 ` Jose R. Santos
2007-10-25 18:43   ` Chris Mason
2007-10-25 22:40     ` Jose R. Santos
2007-10-25 23:45       ` Chris Mason [this message]
2007-10-25 15:54 ` Jose R. Santos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071025194544.25c6dd7f@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.