linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	"Prakash K. Cheemplavam" <prakashkc@gmx.de>,
	marcush@onlinehome.de, linux-kernel@vger.kernel.org,
	eric_mudama@Maxtor.com
Subject: Re: Silicon Image 3112A SATA trouble
Date: Sun, 30 Nov 2003 12:18:42 -0500	[thread overview]
Message-ID: <3FCA2672.8020202@pobox.com> (raw)
In-Reply-To: <20031130165146.GY10679@suse.de>

Jens Axboe wrote:
> On Sun, Nov 30 2003, Jeff Garzik wrote:
>>fond of partial completions, as I feel they add complexity, particularly 
>>so in my case:  I can simply use the same error paths for both the 
>>single-sector taskfile and the "everything else" taskfile, regardless of 
>>which taskfile throws the error.
> 
> 
> It's just a questions of maintaining the proper request state so you
> know how much and what part of a request is pending. Requests have been
> handled this way ever since clustered requests, that is why
> current_nr_sectors differs from nr_sectors. And with hard_* duplicates,
> it's pretty easy to extend this a bit. I don't see this as something
> complex, and if the alternative you are suggesting (your implementation
> idea is not clear to me...) is to fork another request then I think it's
> a lot better.
[snip howto]

Yeah, I know how to do partial completions.  The increased complexity 
arises in my driver.  It's simply less code in my driver to treat each 
transaction as an "all or none" affair.

For the vastly common case, it's less i-cache and less interrupts to do 
all-or-none.  In the future I'll probably want to put partial 
completions in the error path...


>>(thinking out loud)  Though best for simplicity, I am curious if a 
>>succession of "tiny/huge" transaction pairs are efficient?  I am hoping 
>>that the drive's cache, coupled with the fact that each pair of 
>>taskfiles is sequentially contiguous, will not hurt speed too much over 
>>a non-errata configuration...
> 
> 
> My gut would say rather two 64kb than a 124 and 4kb. But you should do
> the numbers, of course :). I'd be surprised if the former wouldn't be
> more efficient.

That's why I was thinking out loud, and also why I CC'd Eric :)  We'll 
see.  I'll implement whichever is easier first, which will certainly be 
better than the current sledgehammer limit.  Any improvement over the 
current code will provide dramatic performance increases, and we can 
tune after that...

	Jeff




  parent reply	other threads:[~2003-11-30 17:19 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 [this message]
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
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=3FCA2672.8020202@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=eric_mudama@Maxtor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcush@onlinehome.de \
    --cc=prakashkc@gmx.de \
    /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).