From: Jens Axboe <jens.axboe@oracle.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
Jeff Moyer <jmoyer@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Shaohua Li <shaohua.li@intel.com>,
Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
#@kernel.dk, This@kernel.dk, line@kernel.dk, is@kernel.dk,
"ignored."@kernel.dk
Subject: Re: [RFC, PATCH 0/2] Reworking seeky detection for 2.6.34
Date: Sun, 28 Feb 2010 19:41:40 +0100 [thread overview]
Message-ID: <20100228184140.GF5768@kernel.dk> (raw)
In-Reply-To: <1267296340-3820-1-git-send-email-czoccolo@gmail.com>
On Sat, Feb 27 2010, Corrado Zoccolo wrote:
>
> Hi, I'm resending the rework seeky detection patch, together with
> the companion patch for SSDs, in order to get some testing on more
> hardware.
>
> The first patch in the series fixes a regression introduced in 2.6.33
> for random mmap reads of more than one page, when multiple processes
> are competing for the disk.
> There is at least one HW RAID controller where it reduces performance,
> though (but this controller generally performs worse with CFQ than
> with NOOP, probably because it is performing non-work-conserving
> I/O scheduling inside), so more testing on RAIDs is appreciated.
>
> The second patch changes the seeky detection logic to be meaningful
> also for SSDs. A seeky request is one that doesn't utilize the full
> bandwidth for the device. For SSDs, this happens for small requests,
> regardless of their location.
> With this change, the grouping of "seeky" requests done by CFQ can
> result in a fairer distribution of disk service time among processes.
Thanks, I have applied this.
--
Jens Axboe
next prev parent reply other threads:[~2010-02-28 18:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1267296340-3820-1-git-send-email-czoccolo@gmail.com>
2010-02-27 18:45 ` [PATCH 1/2] cfq-iosched: rework seeky detection Corrado Zoccolo
2010-02-27 18:45 ` [PATCH 2/2] cfq-iosched: rethink seeky detection for SSDs Corrado Zoccolo
2010-03-01 14:25 ` Vivek Goyal
2010-03-03 19:47 ` Corrado Zoccolo
2010-03-03 21:21 ` Vivek Goyal
2010-03-03 23:28 ` Vivek Goyal
2010-03-04 20:34 ` Corrado Zoccolo
2010-03-04 22:27 ` Vivek Goyal
2010-03-05 22:31 ` Corrado Zoccolo
2010-03-08 14:08 ` Vivek Goyal
2010-02-28 18:41 ` Jens Axboe [this message]
2010-03-01 16:35 ` [RFC, PATCH 0/2] Reworking seeky detection for 2.6.34 Vivek Goyal
2010-03-01 19:45 ` Vivek Goyal
2010-03-01 23:01 ` Corrado Zoccolo
2010-03-03 22:39 ` Corrado Zoccolo
2010-03-03 23:11 ` 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=20100228184140.GF5768@kernel.dk \
--to=jens.axboe@oracle.com \
--cc="ignored."@kernel.dk \
--cc=#@kernel.dk \
--cc=This@kernel.dk \
--cc=czoccolo@gmail.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=is@kernel.dk \
--cc=jmoyer@redhat.com \
--cc=line@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=vgoyal@redhat.com \
/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