Re: [PATCH] speed up SATA

From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 03/28/04

  • Next message: Jens Axboe: "Re: [PATCH] speed up SATA" 
    Date:	Sun, 28 Mar 2004 10:12:23 -0800
To: Jens Axboe <axboe@suse.de>

    On Sun, Mar 28, 2004 at 07:54:36PM +0200, Jens Axboe wrote:
    > Sorry, but I cannot disagree more. You think an artificial limit at the
    > block layer is better than one imposed at the driver end, which actually
    > has a lot more of an understanding of what hardware it is driving? This
    > makes zero sense to me. Take floppy.c for instance, I really don't want
    > 1MB requests there, since that would take a minute to complete. And I
    > might not want 1MB requests on my Super-ZXY storage, because that beast
    > completes io easily at an iorate of 200MB/sec.
    > So you want to put this _policy_ in the block layer, instead of in the
    > driver. That's an even worse decision if your reasoning is policy. The
    > only such limits I would want to put in, are those of the bio where
    > simply is best to keep that small and contained within a single page to
    > avoid higher order allocations to do io. Limits based on general sound
    > principles, not something that caters to some particular piece of
    > hardware. I absolutely refuse to put a global block layer 'optimal io
    > size' restriction in, since that is the ugliest of policies and without
    > having _any_ knowledge of what the hardware can do.

    How about per-device policies and driver hints wrt. optimal io?

    -- wli
    -
    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: Jens Axboe: "Re: [PATCH] speed up SATA"

    Relevant Pages

    • Re: RFD: Kernel release numbering
      ... > patch and fixing the driver for the people it's broken for exceeds such ... Then either the patch author splits out the bug if they want to, ... I feel that imposing such limits is the only way this can be done and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] speed up SATA
      ... >> block layer is better than one imposed at the driver end, ... Limits based on general sound ... user-tunable per-device policies with sane driver defaults. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] speed up SATA
      ... > predates segment boundary support in block layer (IDE never relied on it). ... double-check and make sure IDE driver supports the worst case, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] kernel: use kcalloc instead kmalloc/memset
      ... Using kcalloc() will check for this same overflow inside kcalloc ... Relying on the current allocation limits would be rather foolish as these ... job of the driver to define reasonable limits, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH: fix block layer ioctl bug
      ... In 2.6.8.1, on a BLKFLSBUF ioctl, if a driver returns ... -EINVAL, the block layer will call fsync_bdev, invalidate_bdev, and ... 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/ ...
      (Linux-Kernel)
    Loading