lkml.org 
[lkml]   [2008]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE
    From
    From: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date: Sun, 20 Jul 2008 09:52:25 -0500

    > Since we're using it successfully in parisc, I don't want the block code
    > removed, but I don't see a reason to force other architectures to use
    > it.
    >
    > However, it has two use cases. One is the legacy one of making rather
    > dumb I/O cards perform better (which is the primary on on parisc), but
    > there is a current one making huge transfers go through SCSI using using
    > the sg_table code. That latter is pretty vital to me since I have to
    > keep the code working, but I don't really have any SCSI cards that can
    > take advantage of it without virtual merging. As a slight irony, IBM is
    > trying to persuade me that a ppc would be better than a parisc for big
    > endian I/O testing ... so I might just be seeing if I can make virtual
    > merging work on power too.

    All of this is gibberish, we've been over this a few times already
    in this thread.

    For a dumb I/O card, you advertise SG_ALL capabilities, the IOMMU
    is going to merge things as it would have anyways, and you have
    code in the driver to advance SG entries after each "dumb I/O".

    There is zero value to the vmerge code, the real gains are being
    realized already.


    \
     
     \ /
      Last update: 2008-07-20 19:25    [W:0.025 / U:0.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site