mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andre Hedrick <andre@linux-ide.org>
To: Timothy Miller <miller@techsource.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Storage Architect Part 1: Re: [PATCH] speed up SATA (resend 3)
Date: Wed, 31 Mar 2004 00:09:35 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.10.10403310003400.11654-100000@master.linux-ide.org> (raw)
In-Reply-To: <406993D1.8040705@techsource.com>


Tim,

I do not know where you have been hiding, but you get it!

NanoSecond timers to determine command respond for storage statics goes
far beyond the latency issues (imho are bogus).  Bogus meaning there are
no known (to me) means to profile kernel performance based on usage.

Desktop, Workstation, Appliance are not equal in needs.

Back to the "NanoSecond timers" one can also generate drive predictive
failure rates.  Determinations based on slip or oob sector access from an
unrecorded sector reallocation event.

At least someone out there is thinking and appears to own one of the few
and rare "Andre to Human" translators.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Tue, 30 Mar 2004, Timothy Miller wrote:

> Somehow I missed this discussion on the list, but I caught it on kerneltrap.
> 
> Anyhow, what I don't understand is why it would be so hard to have the 
> block layer measure latency and dynamically adjust for each device. 
> Start somewhat small, and when the block layer sees that a given device 
> can handle larger requests without blowing latency requirements, 
> increase the request size.  Keep a running average.
> 


      reply	other threads:[~2004-03-31  8:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-30  8:01 Andre Hedrick
2004-03-30 15:35 ` Timothy Miller
2004-03-31  8:09   ` Andre Hedrick [this message]

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=Pine.LNX.4.10.10403310003400.11654-100000@master.linux-ide.org \
    --to=andre@linux-ide.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    /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

all inboxes | Powered by JetHome®