From: Paulo Marques <pmarques@grupopie.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jakob Oestergaard <jakob@unthought.net>,
Arjan van de Ven <arjan@infradead.org>,
"Phetteplace, Thad (GE Healthcare,
consultant)" <Thad.Phetteplace@ge.com>,
linux-kernel@vger.kernel.org
Subject: Re: Bandwidth Allocations under CFQ I/O Scheduler
Date: Wed, 18 Oct 2006 14:51:05 +0100 [thread overview]
Message-ID: <45363149.9050607@grupopie.com> (raw)
In-Reply-To: <20061018130456.GJ24452@kernel.dk>
Jens Axboe wrote:
>[...]
> Precisely, hence CFQ is now based on the time metric. Given larger
> slices, you can mostly eliminate the impact of other applications in the
> system.
Just one thought: we can't predict reliably how much time a request will
take to be serviced, but we can account the time it _took_ to service a
request.
If we account the time it took to service requests for each process, and
we have several processes with requests pending, we can use the same
algorithm we would use for a large time slice algorithm to select the
process to service.
This should make it as fair over time as a large time slice algorithm
and doesn't need large time slices, so latencies can be kept as low as
required.
However, having a small time slice will probably help the hardware
coalesce several request from the same process that are more likely to
be to nearby sectors, and thus improve performance.
I'm leaving out the details, like we should find a way to make the
"fairness" work over a time window and not over the entire process
lifespan, maybe by using a sliding window over the last N seconds of
serviced requests to do the accounting or something.
--
Paulo Marques - www.grupopie.com
"The face of a child can say it all, especially the
mouth part of the face."
next prev parent reply other threads:[~2006-10-18 13:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-16 20:46 Bandwidth Allocations under CFQ I/O Scheduler Phetteplace, Thad (GE Healthcare, consultant)
2006-10-17 1:24 ` Arjan van de Ven
2006-10-17 13:23 ` Jens Axboe
2006-10-17 14:37 ` Ric Wheeler
2006-10-17 14:47 ` Jens Axboe
2006-10-17 14:46 ` Phetteplace, Thad (GE Healthcare, consultant)
2006-10-18 8:00 ` Jakob Oestergaard
2006-10-18 9:40 ` Arjan van de Ven
2006-10-18 11:30 ` Jakob Oestergaard
2006-10-18 11:49 ` Jens Axboe
2006-10-18 12:23 ` Jakob Oestergaard
2006-10-18 12:42 ` Alan Cox
2006-10-18 12:44 ` Jens Axboe
2006-10-18 12:55 ` Nick Piggin
2006-10-18 13:04 ` Jens Axboe
2006-10-18 13:39 ` Jakob Oestergaard
2006-10-18 13:51 ` Paulo Marques [this message]
2006-10-19 12:22 ` Jens Axboe
2006-10-18 13:37 ` Jakob Oestergaard
2006-10-18 12:44 ` Jakob Oestergaard
2006-10-18 12:42 ` Jens Axboe
2006-10-18 13:35 ` Jakob Oestergaard
2006-10-18 9:51 ` Jens Axboe
2006-10-18 11:00 ` Helge Hafting
2006-10-18 11:14 ` Jens Axboe
2006-10-18 11:23 ` Ric Wheeler
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=45363149.9050607@grupopie.com \
--to=pmarques@grupopie.com \
--cc=Thad.Phetteplace@ge.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=jakob@unthought.net \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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