public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCHES] add ata scsi driver
Date: Mon, 26 May 2003 22:51:46 +0200	[thread overview]
Message-ID: <20030526205146.GS845@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0305261339340.13489-100000@home.transmeta.com>

On Mon, May 26 2003, Linus Torvalds wrote:
> 
> On 26 May 2003, James Bottomley wrote:
> > 
> > > I'd hate for SATA to pick up these kinds of mistakes from the SCSI layer.
> > 
> > The elevator is based on linear head movements.
> 
> Historically, yes.
> 
> But we've been moving more and more towards a latency-based elevator, or
> at least one that takes latency into account. Which is exactly why you'd
> like to leave unfinished requests on the queue, because otherwise your
> queue doesn't really show what is really going on.

The newer io schedulers divide the queue into a front and backend, so
it's not exactly trivial to just 'leave it on the queue'. Which queue?

You know which ones are pending, they are on the busy queue. You can
look there.

> In particular, while the higher layers don't actually _do_ this yet, from 
> a latency standpoint the right thing to do when some request seems to get 
> starved is to refuse to feed more tagged requeusts to the device until the 
> starved request has finished. 

Agree

> As I mentioned, Andrew actually had some really bad latency numbers to
> prove that this is a real issue. SCSI with more than 4 tags or so results 
> in potentially _major_ starvation, because the disks themselves are not 
> even trying to avoid it.

Basically everyone agrees that this shouldn't happen in newer disks, I'm
inclined to think we are seeing internal queueing bugs in the SCSI
drivers or SCSI layer itself.

> Also, even aside from the starvation issue with unfair disks, just from a
> "linear head movement" standpoint, you really want to sort the queue
> according to what is going on _now_ in the disk. If the disk eats the
> requests immediately (but doesn't execute them immediately), the sorting
> has nothing to go on, and you get tons of back-and-forth movements.
> 
> Basically, if you're trying to do an elevator, you need to know what the 
> outstanding commands are. Think it through on paper, and you'll see what I 
> mean.

Who said we are using an elevator? News flash, we haven't used an
elevator design for a long time.

-- 
Jens Axboe


  reply	other threads:[~2003-05-26 20:38 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-26 18:12 [BK PATCHES] add ata scsi driver James Bottomley
2003-05-26 18:18 ` Jens Axboe
2003-05-26 18:47   ` James Bottomley
2003-05-26 19:07     ` Jens Axboe
2003-05-26 19:17       ` James Bottomley
2003-05-26 19:33         ` Jens Axboe
2003-05-27 12:39           ` Jens Axboe
2003-05-27 14:26             ` James Bottomley
2003-05-27 17:16               ` Jens Axboe
2003-05-27 18:09                 ` James Bottomley
2003-05-27 18:21                   ` Jens Axboe
2003-05-27 18:30                     ` James Bottomley
2003-05-26 20:27         ` Linus Torvalds
2003-05-26 20:36           ` James Bottomley
2003-05-26 20:45             ` Linus Torvalds
2003-05-26 20:51               ` Jens Axboe [this message]
2003-05-26 20:56               ` James Bottomley
2003-05-26 20:38           ` Jens Axboe
2003-05-26 20:49             ` Linus Torvalds
2003-05-26 20:57               ` Jens Axboe
2003-05-26 21:34                 ` Linus Torvalds
2003-05-26 23:58                   ` Nick Piggin
2003-05-27  0:09                     ` Linus Torvalds
2003-05-27  0:49                       ` Nick Piggin
2003-05-27  0:16                   ` Alan Cox
2003-05-27  6:54                   ` Jens Axboe
2003-05-27 14:20                     ` James Bottomley
2003-05-27 14:36                     ` Linus Torvalds
2003-05-27 14:59                       ` James Bottomley
2003-05-27 15:21                         ` Jeff Garzik
2003-05-27 15:38                           ` James Bottomley
2003-05-27 15:50                             ` Jeff Garzik
2003-05-27 16:00                               ` James Bottomley
2003-05-27 16:16                                 ` Jeff Garzik
2003-05-28  9:35                                   ` Christoph Hellwig
2003-05-28 10:50                           ` Lincoln Dale
2003-05-27 19:43                       ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2003-05-26  4:58 Jeff Garzik
2003-05-26  5:15 ` Linus Torvalds
2003-05-26  5:30   ` Jeff Garzik
2003-05-26  5:36     ` Jeff Garzik
2003-05-26  5:42       ` Linus Torvalds
2003-05-26  6:01         ` Jeff Garzik
2003-05-26 16:56           ` Linus Torvalds
2003-05-26 17:47             ` Jeff Garzik
2003-05-26 20:09               ` Linus Torvalds
2003-05-27  0:29                 ` Alan Cox
2003-05-27  6:07                 ` Jeff Garzik
2003-05-27  6:30                   ` Linus Torvalds
2003-05-27  6:51                     ` Linus Torvalds
2003-05-27  7:29                       ` Jeff Garzik
2003-05-26  5:40     ` Linus Torvalds
2003-05-26  5:53       ` Jeff Garzik
2003-05-26  6:21         ` Jeff Garzik
2003-05-26 16:57           ` Linus Torvalds
2003-05-26 17:24             ` Jens Axboe
2003-05-26 17:54               ` Jeff Garzik
2003-05-26 17:59               ` Jeff Garzik
2003-05-26 18:11                 ` Jens Axboe
2003-05-27  0:22       ` Alan Cox
2003-05-27  4:15         ` Linus Torvalds
2003-05-26 10:32     ` Bartlomiej Zolnierkiewicz
2003-05-26 11:13       ` Jeff Garzik
2003-05-26 11:37         ` Bartlomiej Zolnierkiewicz
2003-05-26  5:59 ` Benjamin Herrenschmidt
2003-05-26  6:03   ` Jeff Garzik
2003-06-02  9:46 ` Andre Hedrick
2003-06-02 13:56   ` Alan Cox

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=20030526205146.GS845@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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