linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <mszeredi@suse.cz>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>, Suresh Jayaraman <sjayaraman@suse.de>
Subject: Re: CFQ read performance regression
Date: Wed, 21 Apr 2010 15:25:24 +0200	[thread overview]
Message-ID: <1271856324.24780.285.camel@tucsk.pomaz.szeredi.hu> (raw)
In-Reply-To: <j2t4e5e476b1004201350xbd08a002l3329fbdd4fb1b8db@mail.gmail.com>

Corrado,

On Tue, 2010-04-20 at 22:50 +0200, Corrado Zoccolo wrote:
> can you give more information about the setup?
> How much memory do you have, what is the disk configuration (is this a
> hw raid?) and so on.

8G of memory 8-way Xeon CPU, fiber channel attached storage array (HP
HSV200).  I don't know the configuration of the array.

> > low_latency is set to zero in all tests.
> >
> > The layout difference doesn't explain why setting the scheduler to
> > "noop" consistently speeds up read throughput in 8-thread tiobench to
> > almost twice.  This fact alone pretty clearly indicates that the I/O
> > scheduler is the culprit.
> From the attached btt output, I see that a lot of time is spent
> waiting to allocate new request structures.
> > S2G               0.022460311   6.581680621  23.144763751          15
> Since noop doesn't attach fancy data to each request, it can save
> those allocations, thus resulting in no sleeps.
> The delays in allocation, though, may not be completely imputable to
> the I/O scheduler, and working in constrained memory conditions will
> negatively affect it.

I verified with the simple dd test that this happens even if there's no
memory pressure from the cache by dd-ing only 5G of files, after
clearing the cache.  This way ~2G of memory are completely free
throughout the test. 

> > I've also tested with plain "dd" instead of tiobench where the
> > filesystem layout stayed exactly the same between tests.  Still the
> > speed difference is there.
> Does dropping caches before the read test change the situation?

In all my tests I drop caches before running it.

Please let me know if you need more information.

Thanks,
Miklos


  reply	other threads:[~2010-04-21 13:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16 12:27 CFQ read performance regression Miklos Szeredi
2010-04-16 17:06 ` Chris
2010-04-17 12:46 ` Corrado Zoccolo
2010-04-19 11:46   ` Miklos Szeredi
2010-04-20 20:50     ` Corrado Zoccolo
2010-04-21 13:25       ` Miklos Szeredi [this message]
2010-04-21 16:05         ` Miklos Szeredi
2010-04-22  7:59           ` Corrado Zoccolo
2010-04-22 10:23             ` Miklos Szeredi
2010-04-22 15:53               ` Jan Kara
2010-04-23 10:48                 ` Miklos Szeredi
2010-04-22 20:31             ` Vivek Goyal
2010-04-23 10:57               ` Miklos Szeredi
2010-04-24 20:36                 ` Corrado Zoccolo
2010-04-26 13:50                   ` Vivek Goyal
2010-04-26 19:14                   ` Vivek Goyal
2010-04-27 17:25                     ` Corrado Zoccolo
2010-04-28 20:02                       ` Vivek Goyal
2010-05-01 12:13                         ` Corrado Zoccolo
2010-06-14 17:59                           ` Miklos Szeredi
2010-06-14 18:06                             ` Vivek Goyal

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=1271856324.24780.285.camel@tucsk.pomaz.szeredi.hu \
    --to=mszeredi@suse.cz \
    --cc=czoccolo@gmail.com \
    --cc=jack@suse.cz \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sjayaraman@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).