[lkml]   [2003]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.69, IDE TCQ can't be enabled
On Mon, 12 May 2003, Oleg Drokin wrote:

> How do you think people will test code that is removed?

The people most likely to fix it know there's a problem, why leave it
around to corrupt filesystems? Leave the code if Jens thinks he will get
to it before 2.6, but comment out the option until he does.

> Or do you mean that nobody plans to look at this ever?

Jens plans to, but there are other things on his plate.

> I remember that Jens Axboe promised to take a look at it some
> months ago.

On Mon, 12 May 2003, Jeff Garzik wrote:

> On Mon, May 12, 2003 at 11:58:10AM -0600, Mudama, Eric wrote:
> > The only difference between SATA TCQ and PATA TCQ is that in PATA TCQ, the
> > drive doesn't report the active tag bitmap back to the host after each
> > command. Other than that they are functionally identical to my
> > understanding. (Yes, there are options like first-party DMA, but these are
> > not requirements)
> That's from the "drive side." From the OS side, the ideal
> implementation isn't here yet :)
> Ideally there is a DMA ring of taskfiles and scatterlists. The OS
> (producer) queues these up asynchrously, and the host+devices
> (consumer) executes the taskfiles in the ring. AHCI does this.
> With PATA TCQ, we only have a single scatterlist, and are forced to
> have more OS-side infrastructure for command queueing, processing, etc.
> As an aside, as drives and hosts get faster, we will actually want
> _fewer_ interrupts (i.e. interrupt coalescing).
> All this points to making the host smarter.
> The drives are already pretty damn smart ;-)

Unfortunately it depends on the drive actually working if it claims to
support the feature. That seems to be a problem.

On Mon, 12 May 2003, Mudama, Eric wrote:

> 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.
> Increasing queue depth reduces the average seek time between commands, both
> in distance and rotational latency. Provided a drive doesn't do dumb stuff
> like we discussed earlier, then it should be good.

One problem which seems probable is that the drive knows less about the
system than the o/s (I hope!) and therefore it can only optimize the order
of i/o for most i/o in the shortest time. It would seem that the deadline
scheduler benefits from doing not the quickest thing but the correct thing
in terms of ordering. I believe that once the i/o is queued (assuming the
drive works right) the drive makes the decision about i/o order. That may
be the wrong thing to do under load, and starve some processes.

There was discussion recently about limiting the requests with SCSI, for
just this reason.

Unless there's a *lot* of gain from doing TCQ, perhaps this should either
wait, be dropped, or only be enabled for a whitelist of known actually
functional drives. Seems like a poor risk to benefit ratio if it doesn't
work just right, and perhaps this should go on the "it seemed like a good
idea at the time" pile. There's nothing the code can do to guard against
bad drive firmware except not use it.

bill davidsen <>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.113 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site