From: Jan Kara <jack@suse.cz>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Jan Kara <jack@suse.cz>,
jens.axboe@oracle.com, LKML <linux-kernel@vger.kernel.org>,
Chris Mason <chris.mason@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Galbraith <efault@gmx.de>,
mszeredi@suse.de
Subject: Re: Performance regression in IO scheduler still there
Date: Mon, 16 Nov 2009 17:58:04 +0100 [thread overview]
Message-ID: <20091116165804.GA19230@duck.suse.cz> (raw)
In-Reply-To: <20091116104744.GC23231@duck.suse.cz>
On Mon 16-11-09 11:47:44, Jan Kara wrote:
> On Thu 12-11-09 15:44:02, Jeff Moyer wrote:
> > Jan Kara <jack@suse.cz> writes:
> >
> > > On Wed 11-11-09 12:43:30, Jeff Moyer wrote:
> > >> Jan Kara <jack@suse.cz> writes:
> > >>
> > >> > Sadly, I don't see the improvement you can see :(. The numbers are the
> > >> > same regardless low_latency set to 0:
> > >> > 2.6.32-rc5 low_latency = 0:
> > >> > 37.39 36.43 36.51 -> 36.776667 0.434920
> > >> > But my testing environment is a plain SATA drive so that probably
> > >> > explains the difference...
> > >>
> > >> I just retested (10 runs for each kernel) on a SATA disk with no NCQ
> > >> support and I could not see a difference. I'll try to dig up a disk
> > >> that support NCQ. Is that what you're using for testing?
> > > I don't think I am. How do I find out?
> >
> > Good question. ;-) I grep for NCQ in dmesg output and make sure it's
> > greater than 0/32. There may be a better way, though.
> Message in the logs:
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-8: Hitachi HTS722016K9SA00, DCDOC54P, max UDMA/133
> ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32)
> ata1.00: configured for UDMA/133
> So apparently no NCQ. /sys/block/sda/device/queue_depth shows 1 but I
> guess that's just it's way of saying "no NCQ".
>
> What I thought might make a difference why I'm seeing the drop and you
> are not is size of RAM or number of CPUs vs the tiobench file size or
> number of threads. I'm running on a machine with 2 GB of RAM, using 4 GB
> filesize. The machine has 2 cores and I'm using 16 tiobench threads. I'm
> now rerunning tests with various numbers of threads to see how big
> difference it makes.
OK, here are the numbers (3 runs of each test):
2.6.29:
Threads Avg Stddev
1 42.043333 0.860439
2 40.836667 0.322938
4 41.810000 0.114310
8 40.190000 0.419603
16 39.950000 0.403072
32 39.373333 0.766913
2.6.32-rc7:
Threads Avg Stddev
1 41.580000 0.403072
2 39.163333 0.374641
4 39.483333 0.400111
8 38.560000 0.106145
16 37.966667 0.098770
32 36.476667 0.032998
So apparently the difference between 2.6.29 and 2.6.32-rc7 increases as
the number of threads rises. With how many threads have you been running
when using SATA drive and what machine is it?
I'm now running a test with larger file size (8GB instead of 4) to see
what difference it makes.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2009-11-16 16:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-26 17:20 Performance regression in IO scheduler still there Jan Kara
2009-10-26 17:26 ` Jeff Moyer
2009-11-05 20:10 ` Jeff Moyer
2009-11-05 23:00 ` Corrado Zoccolo
2009-11-06 14:14 ` Jeff Moyer
2009-11-10 18:37 ` Jan Kara
2009-11-06 18:56 ` Jeff Moyer
2009-11-08 17:01 ` Corrado Zoccolo
2009-11-10 16:47 ` Jeff Moyer
2009-11-10 17:37 ` Corrado Zoccolo
2009-11-11 14:10 ` Jan Kara
2009-11-11 17:43 ` Jeff Moyer
2009-11-12 17:29 ` Jan Kara
2009-11-12 20:44 ` Jeff Moyer
2009-11-12 21:00 ` Jens Axboe
2009-11-12 21:05 ` Jeff Moyer
2009-11-13 7:45 ` Jens Axboe
2009-11-16 10:47 ` Jan Kara
2009-11-16 16:58 ` Jan Kara [this message]
2009-11-16 17:03 ` Jeff Moyer
2009-11-16 18:38 ` Corrado Zoccolo
2009-11-16 22:17 ` Jan Kara
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=20091116165804.GA19230@duck.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=efault@gmx.de \
--cc=jens.axboe@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@suse.de \
/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.