lkml.org 
[lkml]   [2002]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.5.3-pre1-aia1
    On Mon, 21 Jan 2002, Jens Axboe wrote:

    > On Mon, Jan 21 2002, Andre Hedrick wrote:
    > > > This really sucks, it means we cannot safely use multi mode for a
    > > > variety of request sizes. I agree with your earlier comment. Here's what
    > > > I think we should be doing: when requesting multi mode, limit to 8
    > > > sectors like in your patch. This is by far the most commen multiple,
    > > > that's why. When starting a request, use WIN_MULT* only for cases where
    > > > (rq->nr_sectors % drive->mult_count) == 0. If that doesn't hold, simply
    > > > use WIN_READ or WIN_WRITE.
    > > >
    > > > Applied the 2.5.3-pre2 sched SMP fix, booting -pre2 and then hacking up
    > > > a patch.
    > >
    > > Why I have already done it, just take and apply.
    >
    > Cool, where is it?

    Attached, and please do not pick and choose.

    I moved and added things for a reason as not to loose hard work, because
    of writing the ISR's to the purity of the spec, and then we modify ISR's
    to fit the kernel and not the other way around. I do have a just reason
    to request a MEMPOOL, which would be exclusively used for PIO operations.
    Then we get out of the mess we are in and get in to serious compliance to
    how the hardware works.

    Thus in the offline comments about the creation of an ata_request_struct,
    a mempool allocation for PIO is justified. Since the correct solution of
    DMA timeouts is to void the request and assume no data down is valid.
    Thus PIO is next.

    If we look at the overhead in the generation of a new request for each and
    every time we do a PIO transfer it is scary. Think about this issue for
    more than the time it takes to hit the delete key.

    Respectfully,

    Andre Hedrick
    Linux Disk Certification Project Linux ATA Development

    -
    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 13:15    [W:0.078 / U:92.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site