From: Paolo Valente <paolo.valente@unimore.it>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org
Subject: Re: [RESEND][RFC] BFQ I/O Scheduler
Date: Thu, 17 Apr 2008 10:26:10 +0200 [thread overview]
Message-ID: <480709A2.7040606@unimore.it> (raw)
In-Reply-To: <20080417071012.GP12774@kernel.dk>
Jens Axboe ha scritto:
>> Actually, in the worst case among our tests, the aggregate throughput
>> with 4k sectors was ~ 20 MB/s, hence the time for 4k sectors ~ 4k * 512
>> / 20M = 100 ms.
>>
>
> That's not worse case, it is pretty close to BEST case.
Yes. 100 ms is just the worst case among our tests with 4k, but these
tests are limited to not much more than simultaneous sequential reads.
> Worst case is 4k
> of sectors, with each being a 512b IO and causing a full stroke seek.
> For that type of workload, even a modern sata hard drive will be doing
> 500kb/sec or less. That's rougly a thousand sectors per seconds, so ~4
> seconds worst case for 4k sectors.
>
In my opinion, the time-slice approach of cfq is definitely better
suited than the (sector) budget approach for this type of workloads. On
the opposite end, the price of time-slices is unfairness towards, e.g.,
threads doing sequential accesses. In bfq we were mainly thinking about
file copy, ftp, video streaming and so on. I was not able to find a good
solution for both types of workloads.
BTW, there is also another possibility. The internal scheduler of bfq
may be used to schedule time-slices instead of budgets. By doing so, the
O(1) instead of O(N) delay/jitter would still be guaranteed (as it is
probably already clear, bfq is obtained from cfq by just turning slices
into budgets, and the Round Robin-like scheduling policy into a Weighted
Fair Queueuing one).
next prev parent reply other threads:[~2008-04-17 8:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-01 15:29 [RESEND][RFC] BFQ I/O Scheduler Fabio Checconi
2008-04-15 8:22 ` Jens Axboe
2008-04-15 9:11 ` Fabio Checconi
2008-04-15 12:42 ` Jens Axboe
2008-04-15 18:08 ` Fabio Checconi
2008-04-16 6:48 ` Paolo Valente
2008-04-18 1:26 ` Aaron Carroll
2008-04-16 18:44 ` Pavel Machek
2008-04-17 6:14 ` Paolo Valente
2008-04-17 7:10 ` Jens Axboe
2008-04-17 8:26 ` Paolo Valente [this message]
2008-04-17 8:30 ` Jens Axboe
2008-04-17 9:24 ` Paolo Valente
2008-04-17 9:27 ` Jens Axboe
2008-04-17 10:19 ` Aaron Carroll
2008-04-17 10:21 ` Jens Axboe
2008-04-17 11:30 ` Fabio Checconi
2008-04-17 15:19 ` Avi Kivity
2008-04-17 15:47 ` Paolo Valente
2008-04-17 15:51 ` Avi Kivity
2008-04-17 18:12 ` Paolo Valente
2008-04-17 23:44 ` Aaron Carroll
2008-04-17 10:24 ` Aaron Carroll
2008-04-17 11:14 ` Fabio Checconi
2008-04-17 12:14 ` Aaron Carroll
2008-04-17 13:54 ` Jens Axboe
2008-04-17 15:18 ` Paolo Valente
2008-04-17 8:48 ` Pavel Machek
2008-04-17 8:57 ` Jens Axboe
2008-04-17 9:14 ` Fabio Checconi
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=480709A2.7040606@unimore.it \
--to=paolo.valente@unimore.it \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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).