lkml.org 
[lkml]   [2004]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] speed up SATA
    On Sun, Mar 28 2004, Jeff Garzik wrote:
    > >The driver may not know exactly, but it does know a ball park figure.
    > >You know if you are driving floppy (sucky transfer and latency), hard
    > >drive, cdrom (decent transfer, sucky seeks), etc.
    >
    > Agreed. Really we have two types of information:
    > * the device's hard limit
    > * the default limit that should be applied to that class of devices
    >
    > I would much rather do something like
    >
    > blk_queue_set_class(q, CLASS_DISK)
    >
    > and have that default per-class policy
    >
    > switch (class) {
    > case CLASS_DISK:
    > q->max_sectors = min(q->max_sectors, CLASS_DISK_MAX_SECTORS);
    > ...

    Oh god no, I was afraid you'd come up with something like this :-). I'm
    quite sure this will lead to an unmaintainable mess, as more and various
    different classes are introduced. Don't try to model something that you
    really cannot model.

    > than hardcode the limit in the driver. That's easy and quick. That's a
    > minimal solution that gives me what I want -- don't hardcode generic
    > limits in the driver -- while IMO giving you what you want, a sane limit
    > in an easy way.
    >
    > Right now we are hardcoding the same per-class limits into each floppy
    > driver, each disk driver, etc. At the very least devices that act the
    > same way should all be using the same tunable, whether it's a
    > compile-time tunable (CLASS_xxx_MAX_SECTORS) or a runtime tunable.
    >
    > Long term, the IO scheduler and the VM should really be figuring out the
    > best request size, from zero to <hardware limit>.

    Lets leave it like it is, and try and tweak latencies dynamically. Could
    be used to limit tcq depth, not just request sizes solving two problems
    at once. I already have a tiny bit of keeping this accounting to do
    proper unplugs (right now it just looks at missing requests from the
    pool, doesn't work on tcq).

    --
    Jens Axboe

    -
    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/

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