From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Silicon Image 3112A SATA trouble
Date: Sun, 30 Nov 2003 15:35:26 -0500 [thread overview]
Message-ID: <3FCA548E.7070501@pobox.com> (raw)
In-Reply-To: <20031130193904.GG6454@suse.de>
Jens Axboe wrote:
> On Sun, Nov 30 2003, Jeff Garzik wrote:
>>Since the hardware request API is (and must be) completely decoupled
>>from struct request API, I can achieve 1.5 x non-errata case.
>
> Hmm I don't follow that... Being a bit clever, you could even send off
> both A and B parts of the request in one go. Probably not worth it
> though, that would add some complexity (things like not spanning a page,
> stuff you probably don't want to bother the driver with).
[...]
> Indeed. The partial completions only exist at the driver -> block layer
> (or -> scsi) layer, not talking to the hardware. The hardware always
> gets 'a request', if that just happens to be only a part of a struct
> request so be it.
[...]
> Sure yes, the fewer completions the better. Where do you get the 1.5
> from? You need to split the request handling no matter what for the
> errata path, I would count that as 2 completions.
Taskfile completion and struct request completion are separate. That
results in
* struct request received by libata
* libata detects errata
* libata creates 2 struct ata_queued_cmd's
* libata calls ata_qc_push() 2 times
* Time passes
* ata_qc_complete called 2 times
Option 1: {scsi|block} complete called 2 times, once for each taskfile
Option 2: {scsi|block} complete called 1 time, when both taskfiles are done
one way: 2 h/w completions, 1 struct request completion == 1.5
another way: 2 h/w completions, 2 struct request completions == 2.0
Maybe another way of looking at it:
It's a question of where the state is stored -- in ata_queued_cmd or
entirely in struct request -- and what are the benefits/downsides of each.
When a single struct request causes the initiation of multiple
ata_queued_cmd's, libata must be capable of knowing when multiple
ata_queued_cmds forming a whole have completed. struct request must
also know this. _But_. The key distinction is that libata must handle
multiple requests might not be based on sector progress.
For this SII errata, I _could_ do this at the block layer:
ata_qc_complete() -> blk_end_io(first half of sectors)
ata_qc_complete() -> blk_end_io(some more sectors)
And the request would be completed by the block layer (right?).
But under the hood, libata has to handle these situations:
* One or more ATA commands must complete in succession, before the
struct request may be end_io'd.
* One or more ATA commands must complete asynchronously, before the
struct request may be end_io'd.
* These ATA commands might not be sector based: sometimes aggressive
power management means that libata must issue and complete a PM-related
taskfile, before issuing the {READ|WRITE} DMA passed to it in the struct
request.
I'm already storing and handling this stuff at the hardware-queue level.
(remember hardware queues often bottleneck at the host and/or bus
levels, not necessarily the request_queue level)
So what all this hopefully boils down to is: if I have to do "internal
completions" anyway, it's just more work for libata to separate out the
2 taskfiles into 2 block layer completions. For both errata and
non-errata paths, I can just say "the last taskfile is done, clean up"
Yet another way of looking at it:
In order for all state to be kept at the block layer level, you would
need this check:
if ((rq->expected_taskfiles == rq->completed_taskfiles) &&
(rq->expected_sectors == rq->completed_sectors))
the struct request is "complete"
and each call to end_io would require both a taskfile count and a sector
count, which would increment ->completed_taskfiles and ->completed_sectors.
Note1: s/taskfile/cdb/ if that's your fancy :)
Note2: ->completed_sectors exists today under another name, yes, I know :)
Jeff
next prev parent reply other threads:[~2003-11-30 20:35 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 13:59 Silicon Image 3112A SATA trouble Prakash K. Cheemplavam
2003-11-29 15:39 ` Prakash K. Cheemplavam
2003-11-29 16:38 ` Julien Oster
2003-11-29 16:54 ` Jeff Garzik
2003-11-29 17:07 ` Craig Bradney
2003-11-30 1:51 ` Prakash K. Cheemplavam
2003-11-29 16:56 ` Jeff Garzik
2003-11-29 17:41 ` Miquel van Smoorenburg
2003-11-29 18:39 ` Jeff Garzik
2003-11-29 20:24 ` Marcus Hartig
2003-11-30 2:00 ` Prakash K. Cheemplavam
2003-11-30 14:47 ` Bartlomiej Zolnierkiewicz
2003-11-30 15:52 ` Prakash K. Cheemplavam
2003-11-30 16:21 ` Bartlomiej Zolnierkiewicz
2003-11-30 16:25 ` Jens Axboe
2003-11-30 16:41 ` Jeff Garzik
2003-11-30 16:51 ` Jens Axboe
2003-11-30 16:58 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:06 ` Jeff Garzik
2003-11-30 17:10 ` Jens Axboe
2003-11-30 17:22 ` Jeff Garzik
2003-11-30 17:31 ` Jens Axboe
2003-11-30 17:48 ` Jeff Garzik
2003-11-30 17:56 ` Vojtech Pavlik
2003-11-30 18:17 ` Jens Axboe
2003-11-30 18:19 ` Jeff Garzik
2003-11-30 18:22 ` Jens Axboe
2003-11-30 18:31 ` Jeff Garzik
2003-11-30 19:44 ` Vojtech Pavlik
2003-11-30 21:05 ` Yaroslav Klyukin
2003-11-30 17:08 ` Jens Axboe
2003-11-30 17:13 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:13 ` Jens Axboe
2003-11-30 17:18 ` Jeff Garzik
2003-11-30 17:28 ` Jens Axboe
2003-11-30 17:41 ` Jeff Garzik
2003-11-30 17:45 ` Jens Axboe
2003-11-30 17:57 ` Jeff Garzik
2003-11-30 18:21 ` Jens Axboe
2003-11-30 19:04 ` Jeff Garzik
2003-11-30 19:39 ` Jens Axboe
2003-11-30 20:35 ` Jeff Garzik [this message]
2003-12-01 9:02 ` Jens Axboe
2003-11-30 17:19 ` Prakash K. Cheemplavam
2003-11-30 18:07 ` Bartlomiej Zolnierkiewicz
2003-11-30 21:34 ` Prakash K. Cheemplavam
2003-11-30 16:27 ` Jeff Garzik
2003-11-30 16:34 ` Bartlomiej Zolnierkiewicz
[not found] <Pine.LNX.4.44.0311291453550.838-100000@coffee.psychology.mcmaster.ca>
2003-11-30 16:45 ` Jeff Garzik
2003-11-30 17:52 Luis Miguel García
2003-11-30 17:13 ` Craig Bradney
2003-11-30 18:27 ` Jeff Garzik
2003-11-30 18:41 Luis Miguel García
2003-11-30 21:15 ` Craig Bradney
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=3FCA548E.7070501@pobox.com \
--to=jgarzik@pobox.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).