From: Vivek Goyal <vgoyal@redhat.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>,
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: Mon, 26 Apr 2010 15:14:53 -0400 [thread overview]
Message-ID: <20100426191453.GE3372@redhat.com> (raw)
In-Reply-To: <s2q4e5e476b1004241336lbd071624ke489350093ca6e1a@mail.gmail.com>
On Sat, Apr 24, 2010 at 10:36:48PM +0200, Corrado Zoccolo wrote:
[..]
> >> Anyway, if that's the case, then we probably need to allow IO from
> >> multiple sequential readers and keep a watch on throughput. If throughput
> >> drops then reduce the number of parallel sequential readers. Not sure how
> >> much of code that is but with multiple cfqq going in parallel, ioprio
> >> logic will more or less stop working in CFQ (on multi-spindle hardware).
> Hi Vivek,
> I tried to implement exactly what you are proposing, see the attached patches.
> I leverage the queue merging features to let multiple cfqqs share the
> disk in the same timeslice.
> I changed the queue split code to trigger on throughput drop instead
> of on seeky pattern, so diverging queues can remain merged if they
> have good throughput. Moreover, I measure the max bandwidth reached by
> single queues and merged queues (you can see the values in the
> bandwidth sysfs file).
> If merged queues can outperform non-merged ones, the queue merging
> code will try to opportunistically merge together queues that cannot
> submit enough requests to fill half of the NCQ slots. I'd like to know
> if you can see any improvements out of this on your hardware. There
> are some magic numbers in the code, you may want to try tuning them.
> Note that, since the opportunistic queue merging will start happening
> only after merged queues have shown to reach higher bandwidth than
> non-merged queues, you should use the disk for a while before trying
> the test (and you can check sysfs), or the merging will not happen.
Hi Corrado,
I ran these patches and I did not see any improvement. I think the reason
being that no cooperative queue merging took place and we did not have
any data for throughput with coop flag on.
#cat /sys/block/dm-3/queue/iosched/bandwidth
230 753 0
I think we need to implement something similiar to hw_tag detection logic
where we allow dispatches from multiple sync-idle queues at a time and try
to observe the BW. After certain window once we have observed the window,
then set the system behavior accordingly.
Kernel=2.6.34-rc5-corrado-multicfq
DIR= /mnt/iostmnt/fio DEV= /dev/mapper/mpathe
Workload=bsr iosched=cfq Filesz=2G bs=4K
==========================================================================
job Set NR ReadBW(KB/s) MaxClat(us) WriteBW(KB/s) MaxClat(us)
--- --- -- ------------ ----------- ------------- -----------
bsr 1 1 126590 61448 0 0
bsr 1 2 127849 242843 0 0
bsr 1 4 131886 508021 0 0
bsr 1 8 131890 398241 0 0
bsr 1 16 129167 454244 0 0
Thanks
Vivek
next prev parent reply other threads:[~2010-04-26 19:15 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
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 [this message]
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=20100426191453.GE3372@redhat.com \
--to=vgoyal@redhat.com \
--cc=czoccolo@gmail.com \
--cc=jack@suse.cz \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@suse.cz \
--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).