All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Alex Tomas <alex@clusterfs.com>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	Andrew Morton <akpm@osdl.org>,
	tytso@mit.edu, pbadari@us.ibm.com, suparna@in.ibm.com,
	gerrit@us.ibm.com, tappro@clusterfs.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ext2-devel@lists.sourceforge.net
Subject: Re: [Ext2-devel] Re: Latest ext3 patches (extents, mballoc, delayed allocation)
Date: Mon, 14 Feb 2005 10:38:22 -0800	[thread overview]
Message-ID: <4210F01E.9070707@us.ibm.com> (raw)
In-Reply-To: <m3y8dude4q.fsf@bzzz.home.net>

Alex Tomas wrote:

> Good day all, 
> 
> I've updated the patchset against 2.6.10. A bunch of bugs have been
> fixed and mballoc now behaves smarter a bit. Extents and mballoc 
> patches collects some stats they print upon umount. NOTE: they must
> not be used to store important data. A lot of things are to be done.
> 

Thanks Alex, for the hard work.

> Please review. Any comments and suggestions are very welcome.

Will do.

> 
> 
> The followins crazy listing shows tiobench's results for SMP box:
> 
> Random Reads
>                               File  Blk   Num                   Avg     CPU
> Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency   Eff
> ---------------------------- ------ ----- ---  ------ ------ --------- -----
> ext2                          512   4096    1  119.05 40.37%     0.031   295
> ext3                          512   4096    1  134.78 37.08%     0.028   363
> ext3rs                        512   4096    1   25.18 8.377%     0.154   301

The throughput here is really weird. Reservation code does not touch 
read code path. I could imagine that it maybe change the disk layout and 
make a difference on sequential reads, but I am not sure how it will 
affect the random read. And this is happening on 1 thread and 4 threads, 
but for 2 threads, reservation case is the best. I will see if I could 
repeat the same results here.

Mingming

  reply	other threads:[~2005-02-14 18:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1106354192.3634.19.camel@dyn318043bld.beaverton.ibm.com>
     [not found] ` <m3hdl2lehb.fsf@bzzz.home.net>
     [not found]   ` <4207BBEA.7090705@us.ibm.com>
2005-02-11 20:40     ` Latest ext3 patches (extents, mballoc, delayed allocation) Alex Tomas
2005-02-14 18:38       ` Mingming Cao [this message]
2005-02-15  7:45       ` [Ext2-devel] " Sonny Rao
2005-02-15  8:08         ` Alex Tomas

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=4210F01E.9070707@us.ibm.com \
    --to=cmm@us.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=akpm@osdl.org \
    --cc=alex@clusterfs.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=gerrit@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=suparna@in.ibm.com \
    --cc=tappro@clusterfs.com \
    --cc=tytso@mit.edu \
    /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.