mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: "Mudama, Eric" <eric_mudama@maxtor.com>
Cc: "'Jens Axboe'" <axboe@suse.de>, Oleg Drokin <green@namesys.com>,
	Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Oliver Neukum <oliver@neukum.org>,
	lkhelp@rekl.yi.org, linux-kernel@vger.kernel.org
Subject: Re: 2.5.69, IDE TCQ can't be enabled
Date: Mon, 12 May 2003 15:35:09 -0400	[thread overview]
Message-ID: <20030512193509.GB10089@gtf.org> (raw)
In-Reply-To: <785F348679A4D5119A0C009027DE33C102E0D31D@mcoexc04.mlm.maxtor.com>

On Mon, May 12, 2003 at 01:19:36PM -0600, Mudama, Eric wrote:
> >You are ignoring the host side of things. PATA TCQ is basically
> >unsupportable without some hardware support (auto-poll). It's my
> >understanding that all SATA controllers do that.
> 
> The drive is always supposed to generate an interrupt when it sets the
> service bit indicating it is ready to receive a service command.
> 
> The release interrupt tells the host the drive is doing a bus release
> following a queued data command.
> 
> The service interrupt tells you you're going DRQ after receiving the service
> command.

Most Linux people with TCQ drives seem to have Hitachi (nee IBM)
ones AFAICS.  These do not have a service interrupt (or at least,
do not report such)

They do have the release interrupt.


> Maybe there are drives out there that don't support the configuration of
> these interrupts... if that is the case, TCQ will never work "well" with
> them since you'll need to poll on timer ticks or something, resulting in a
> huge performance loss.

yep :)


> >Then there's the debate of whether TCQ is worth it at all, in general. I
> >feel that a few tags just to minimize the time spent when ending a
> >request to starting a new one is nice.
> 
> TCQ shouldn't benefit writes significantly from a performance perspective if
> the drive is reasonably smart.  TCQ *will* have a huge performance
> improvement for random reads since the drive can order responses based on
> minimal rotational latency.

You hit the nail on the head.

With the host interface limitation of a single scatterlist
particularly, writes do not benefit very much at all.  However,
since reads can be queued and buffered internally in the drive,
TCQ will definitely show benefits.

Coming from an OS perspective, I think we really want to be able to
queue up a bunch of scatterlists, like the new AHCI spec does.


> >> Personally I'd like to see the option stay in there as experimental, it
> >> helps us drive folks test stuff when we can just flip an option off/on to
> >> get that functionality.
> >
> >I agree, besides it just needs a bit of fixing, can't be much.
> 
> I'll do what I can to help in my spare time.

Great!  Your knowledge and experience is much appreciated.

Regards,

	Jeff




  reply	other threads:[~2003-05-12 19:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-12 19:19 Mudama, Eric
2003-05-12 19:35 ` Jeff Garzik [this message]
2003-05-12 19:42   ` Jens Axboe
2003-05-12 19:44     ` Jens Axboe
2003-05-12 19:53     ` Jeff Garzik
2003-05-13  6:40       ` Jens Axboe
2003-05-13 18:00         ` Dave Jones
2003-05-13 18:03           ` Jens Axboe
2003-05-13 18:05             ` Jeff Garzik
2003-05-13 18:06               ` Jens Axboe
2003-05-13 18:13                 ` Jens Axboe
2003-05-13 18:42                   ` Jeff Garzik
2003-05-13 20:29                     ` Andre Hedrick
2003-05-14  7:04                       ` Jens Axboe
2003-05-14  7:15                     ` Jens Axboe
2003-05-13 20:03                   ` Andre Hedrick
2003-05-13 22:55                     ` Alan Cox
2003-05-13 18:03           ` Jeff Garzik
2003-05-14 13:30           ` Henning P. Schmiedehausen
2003-05-12 22:36     ` Christer Weinigel
2003-05-13  6:41       ` Jens Axboe
2003-05-13 20:04 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2003-05-13 20:43 Mudama, Eric
2003-05-13 20:31 Mudama, Eric
2003-05-13 20:34 ` Andre Hedrick
2003-05-13 20:28 Mudama, Eric
2003-05-12 17:58 Mudama, Eric
2003-05-12 18:59 ` Jens Axboe
2003-05-12 19:42 ` Jeff Garzik
2003-05-10  1:38 lkhelp
2003-05-12 12:46 ` Oleg Drokin
2003-05-12 12:55   ` Oliver Neukum
2003-05-12 13:16     ` Bartlomiej Zolnierkiewicz
2003-05-12 13:12       ` Alan Cox
2003-05-13 15:39         ` Jens Axboe
2003-05-12 13:22       ` Oleg Drokin
2003-05-12 13:23         ` Jens Axboe
2003-05-12 13:35           ` Jeff Garzik
2003-05-12 13:30         ` Bartlomiej Zolnierkiewicz
2003-05-12 13:22       ` Jens Axboe
2003-05-13 15:32       ` Jens Axboe
2003-05-13 17:25         ` Oliver Neukum
2003-05-13 17:28           ` Jens Axboe
2003-05-13 18:46             ` Oliver Neukum
2003-05-13 19:06               ` 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=20030512193509.GB10089@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=axboe@suse.de \
    --cc=eric_mudama@maxtor.com \
    --cc=green@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkhelp@rekl.yi.org \
    --cc=oliver@neukum.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

all inboxes | Powered by JetHome®