[lkml]   [2002]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][CFT] IDE tagged command queueing support
    On Mon, Apr 08 2002, Martin Dalecki wrote:
    > >- Separate scatterlist and dma table out from hwgroup. This is not
    > > really needed for TCQ, but saves doing a blk_rq_map_sg on a request
    > > more than once. If future ATA hardware would support more than one
    > > pending DMA operation per hwgroup, this would be useful even without
    > > TCQ.
    > Agreed.

    If we do this, we need to make a decision about how many segments to
    enable per command. As I stated, current is 32 which gives us (at least)
    128kb per request. This is all we need right now, and I'm not too
    convinced that doing much larger requests with 48-bit lba will buys us
    _anything_ but bigger latency problems :-). This is just my speculation,
    I have no numbers to back this up so far. Now, with a 1kb fs we are
    limited to 32kb requests if we don't get good clustering. This might be
    a small performance hit, but if you are writing big blocks in a 1kb fs
    chances are good thaat you _will_ get good clustering (writing out the 4
    consecutive buffer_heads stringed to the page) so I'm not convinced that
    this will be a problem either.

    So I'd just stick with PRD_SEGMENTS at 32 so far. The over head of going
    to, eg, 64 would be 8 * 64 == 512 bytes per ata_request instead of the
    current 256 right now. Ok, that's not a lot, but still :-)

    > >- Use ata_request_t as the main request command. This is where I really
    > > want to go. I'm not saying that we need a complete IDE mid layer, but
    > > a private request type is a nice way to unify the passing of a general
    > > command around. So the taskfile stuff would remain very low level,
    > > ata_request would add the higher level parts. I could expand lots more
    > > on this, but I'm quite sure you know where I'm going :-)
    > Well I can assure you that we are not dragging the towell in two different
    > directions - please see for example my notes about the ata_taskfile
    > function having too much parameters ;-).

    ata_taskfile(drive, ar);

    or something to that effect should be very possible, it just requires
    taking my generalization a bit further.

    > >Note that the ata_request_t usage is a bit messy in the current patch,
    > I noted it already ;-)

    I didn't want ata_request_t changes to pollute the patch too much :-)

    > >that's merely because I was more focused on getting TCQ stable than
    > >designing this out right now. So I think we should let it mature in the
    > >TCQ patch for just a while before making any final commitments. Agreed?
    > No problem with me. I will just pull out the generally good stuff
    > out of it OK? I hope this will not make the tracking of the
    > alpha patches too difficult for you...

    Yes that's fine with me, and feel free to extend the ata_request stuff
    (and anything else). I'll adapt the tcq stuff and submit when ready.

    > >In addition, there are small buglet fixes in the patch that should go to
    > >general. I will extract these, I already send you one of these earlier
    > >today.
    > Yes I have noticed this as well. However let's wait and see
    > whatever maybe I'm able to save you the trobule and pull them
    > out myself. Your alpha patch is "interresting" enough to have me
    > a walk over it line by line anyway :-).

    Alright, I'll let you ponder the stuff for a while and pull what you

    > I have to catch up with 2.5.8-pre2 anyway, since apparently this
    > weekend was more about alcohol consumption for me then hacking...

    Ahem, yes that part I know too :)

    Jens Axboe

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:22    [W:0.028 / U:7.400 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site