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
next prev parent 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).