From: Wu Fengguang <wfg@mail.ustc.edu.cn>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Fwd: Adaptive read-ahead V12
Date: Fri, 26 May 2006 15:27:39 +0800 [thread overview]
Message-ID: <348628455.03454@ustc.edu.cn> (raw)
Message-ID: <20060526072738.GG5135@mail.ustc.edu.cn> (raw)
----- Forwarded message from Iozone <capps@iozone.org> -----
Subject: Adaptive read-ahead V12
From: Iozone <capps@iozone.org>
To: Wu Fengguang <wfg@mail.ustc.edu.cn>
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
Date: Thu, 25 May 2006 11:44:37 -0500
Wu Fengguang,
I see that Andrew M. is giving you some pushback....
His argument is that the application could do a better job
of scheduling its own read-ahead. ( I've heard this one
before)
My thoughts on this argument would be along the
lines of:
Indeed the application might be able to do a better
job, however expecting, or demanding, the rewrite
of all applications to behave better might be an unreasonable
expectation. Rewriting all the weather codes, all the
structrual analysis codes, all the data-bases, video streaming
and so on, would solve the problem but the timeline for
such an re-codification may approach infinity, while
systems that have the ability to silently increase
performance maintain an advantage in the market.
Note: Many vendors already have sophisticated A.I. read-ahead
algorithms. Examples: Microsoft, Veritas HP, and Isolon.
Linux already does read-ahead that does not require
the application to be involved. It just does it in
a simpler way that could be improved for handling
a wider range of applications. This new technology is
a simple evolutionary step in that direction. Linux read-ahead
and is currently 8 years behind existing technologies in this area.
Isn't it time to catch up a bit ?
Note: You probably will need to reword this before replying
to Andrew, as I tend to be somewhat blunt. :-)
Hint: I took me a while to convince the kernel folks in my
company to accept such a technology. But when the
prototype accelerated one of their key partner's code by
30 % wall clock, and another showed 50X speedup in
file I/O across a wide stripe, that did the trick.
Enjoy,
Don Capps
[...]
----- End forwarded message -----
next reply other threads:[~2006-05-26 7:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060526072738.GG5135@mail.ustc.edu.cn>
2006-05-26 7:27 ` Wu Fengguang [this message]
2006-05-31 20:17 ` Fwd: Adaptive read-ahead V12 Bill Davidsen
[not found] ` <20060601010434.GA5019@mail.ustc.edu.cn>
2006-06-01 1:04 ` Wu Fengguang
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=348628455.03454@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=linux-kernel@vger.kernel.org \
/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