All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.