Re: Silicon Image 3112A SATA trouble

From: Jeff Garzik (jgarzik_at_pobox.com)
Date: 11/30/03

  • Next message: Jeff Garzik: "Re: Silicon Image 3112A SATA trouble" 
    Date:	Sun, 30 Nov 2003 12:18:42 -0500
To: Jens Axboe <axboe@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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jeff Garzik: "Re: Silicon Image 3112A SATA trouble"

    Relevant Pages

    • Re: Silicon Image 3112A SATA trouble
      ... > from struct request API, I can achieve 1.5 x non-errata case. ... The partial completions only exist at the driver -> block layer ...
      (Linux-Kernel)
    • Re: Silicon Image 3112A SATA trouble
      ... I know how to do partial completions. ... It's simply less code in my driver to treat each ... You don't even have to know it's a partial request in the ...
      (Linux-Kernel)
    • Re: Silicon Image 3112A SATA trouble
      ... or for ATAPI submitting the internal ... >>REQUEST SENSE, is quite simple and only a few lines of code. ... > SCSI already does these partial completions... ... partial completions don't make any sense at ...
      (Linux-Kernel)
    • Re: WaitForMultipleObjects , threads and blocking function
      ... request is done. ... EHttpErrorKind eHttpErrKind; ... to have only two kinds of completions: ... The problem arises when the thread is trying to write to server and ...
      (microsoft.public.vc.mfc)
    • Re: Silicon Image 3112A SATA trouble
      ... >>request handling is absolutely so much in the noise. ... You don't even have to know it's a partial request in the ... SCSI already does these partial completions... ... > partial completions in the error path make sense to me. ...
      (Linux-Kernel)