From: Nick Piggin <piggin@cyberone.com.au>
To: Giuliano Pochini <pochini@shiny.it>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: ext2/3 performance regression in 2.6 vs 2.4 for small interl
Date: Thu, 12 Feb 2004 21:27:14 +1100 [thread overview]
Message-ID: <402B5502.2010207@cyberone.com.au> (raw)
In-Reply-To: <XFMail.20040212104215.pochini@shiny.it>
Giuliano Pochini wrote:
>On 12-Feb-2004 Andrea Arcangeli wrote:
>
>
>>the main difference is that 2.4 isn't in function of time, it's in
>>function of requests, no matter how long it takes to write a request,
>>so it's potentially optimizing slow devices when you don't care about
>>latency (deadline can be tuned for each dev via
>>/sys/block/*/queue/iosched/).
>>
>
>IMHO it's the opposite. Transfer speed * seek time of some
>slow devices is lower than fast devices. For example:
>
>Hard disk raw speed= 40MB/s seek time = 8ms
>MO/ZIP raw speed= 3MB/s seek time = 25ms
>
>
I like accounting by time better because its accurate
and fair for all types of devices, however I admit an
auto tuning feature would be nice.
Say you allow 16 128K requests before seeking:
The HD will run the requests for 50ms then seek (8ms).
So this gives you about 86% efficiency.
On your zip drive it takes 666ms, giving you 96%.
Now with AS, allowing 50ms of requests before a seek
gives you the same for an HD, but only 66% for the MO
drive. A CD-ROM will be much worse.
Auto tuning wouldn't be too hard. Just measure the time
it takes for your seeking requests to complete and you
can use the simple formula to allow users to specify a
efficiency vs latency %age.
next prev parent reply other threads:[~2004-02-12 10:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 19:04 ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-11 20:28 ` Rik van Riel
2004-02-11 21:02 ` Michael Frank
2004-02-11 21:18 ` Diego Calleja
2004-02-12 2:00 ` Dave Olien
2004-02-12 2:23 ` Andrea Arcangeli
2004-02-12 9:42 ` ext2/3 performance regression in 2.6 vs 2.4 for small interl Giuliano Pochini
2004-02-12 10:15 ` John Bradford
2004-02-12 10:27 ` Nick Piggin [this message]
2004-02-12 17:05 ` Michael Frank
2004-02-12 17:18 ` Valdis.Kletnieks
2004-02-12 20:55 ` Helge Hafting
2004-02-13 1:57 ` Jamie Lokier
2004-02-13 2:05 ` Nick Piggin
2004-02-12 14:59 ` Andrea Arcangeli
2004-02-13 12:15 ` ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-12 10:40 ` Jon Burgess
2004-02-12 20:17 ` Hans Reiser
2004-02-12 9:56 ` Andrew Morton
2004-02-12 20:20 ` Jon Burgess
2004-02-13 8:28 ` Juan Piernas Canovas
2004-02-16 17:51 ` Alex Zarochentsev
2004-02-16 20:03 ` Jon Burgess
2004-02-13 12:35 ` Jon Burgess
2004-02-14 15:00 ` Jon Burgess
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=402B5502.2010207@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pochini@shiny.it \
/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