All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Martin Dalecki <dalecki@evision-ventures.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] reworked IDE/general tagged command queueing
Date: Wed, 1 May 2002 20:25:03 +0200	[thread overview]
Message-ID: <20020501182503.GE811@suse.de> (raw)
In-Reply-To: <20020501123705.GI837@suse.de> <Pine.LNX.4.44.0205010900050.4589-100000@home.transmeta.com>

On Wed, May 01 2002, Linus Torvalds wrote:
> 
> 
> On Wed, 1 May 2002, Jens Axboe wrote:
> >
> > I've rewritten parts of the IDE TCQ stuff to be, well, a lot better in
> > my oppinion. I had to accept that the ata_request and rq->special usage
> > sucked, it was just one big mess.
> 
> Looks good.
> 
> I would have one more comment - it would be wonderful if somebody else who
> was using tagged commands were to try to use this interface too, just to
> verify that it doesn't have any major problems.
> 
> I'll be happy to merge the generic tag stuff even without that (on the
> assumption that whatever deficiencies can be fixed later anyway), but it
> would be wonderful to have some kind of validation of the genericity.
> 
> In particular, on an IDE TCQ device we expect the queue depth to be fixed,
> but the SCSI subsystem considers queue depth to be only approximate
> (because the drive internally might split a command or something, I don't
> know). So I wonder how well this interface would interact with the
> QUEUE_FULL handling that the SCSI layer does.
> 
> Maybe it doesn't matter, and maybe some blk_queue_invalidate_tags() magic
> could do the right thing, but I'd like to get some kind of idea of whether
> others can use it well..
> 
> (If not the SCSI layer, maybe somebody could look at DAC960 or cciss and
> see whether they would seem to like the tag interface).

Yeah, that's why I said the interface was simple on purpose right now.
I'm sure it's extendable for some sort of adaptive queueing as well, I
will try to provide some examples for that. cciss will eat a lot more
commands than you think, it typically has a bigger internal queue depth
than the block layer :-). If not dac960, then SCSI is a possibility.

-- 
Jens Axboe


  parent reply	other threads:[~2002-05-01 18:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-01 12:37 [PATCH] reworked IDE/general tagged command queueing Jens Axboe
2002-05-01 16:08 ` Linus Torvalds
2002-05-01 16:02   ` Martin Dalecki
2002-05-01 17:09     ` Martin Dalecki
2002-05-01 18:25       ` Jens Axboe
2002-05-01 18:25   ` Jens Axboe [this message]
2002-05-01 16:22 ` Martin Dalecki
2002-05-01 19:08   ` Jens Axboe

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=20020501182503.GE811@suse.de \
    --to=axboe@suse.de \
    --cc=dalecki@evision-ventures.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.