public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 -----

             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