On Mon, Jan 21 2002, Andre Hedrick wrote:
> In PIO there is no scatter gather possible without a memcpy to a
> contigious buffer period. Therefore under the contstraints issued bu
Why?
> Linus and Jens, of access to one 4k page of memory, and a forced
> requirement to return back every 4k page of memory of completion prevents
> one from ever transaction more than 8 sectors per request in PIO any mode.
You don't understand... It's not forced, it's just _the sane way to do
it_. When you finish I/O on a chunk of data, end I/O on that chunk of
data. This doesn definitely _not_ prevent transaction of more than 8
sectors per request, that's nonsense. It's only that way in the current
kernel because it was easy to get right the first time around. And it's
only in multi-write, oh look at multi-read, that does 16 sectors at the
time. Weee!
> start_request_sectors (255 sectors) max
>
> make_request (start_request_sectors())
>
> do_request()
> ide-disk get (255 sectors)
> block truncates to 8 sectors max
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wrong
> ide-taskfile
> transfers 8 sectors max
^^^^^^^^^^^^^^^^^^^^^^^
Wrong
> end request (return 247 sectors)
>
> upate_request(247 to be re issued, + additional max of 8)
end_request _is_ the update request. You seem to not understand that
calling ide_end_request does not mean that we are terminating the
request from the host side, we are merely asking the block layer to
complete xxx amount of sectors for us so we can continue doing the
request residual.
> make_request (247 to be re issued, + additional max of 8)
Very wrong, make_request is never called here. Let me out line what
happens. Do you really mean start_request, if so then yes.
> This is why I am going to request for backing out again because the BLOCK
> API without a MID-LAYER to buffer against the goal of the kernel,
> conflicts with the hardware rules requirements. Until a satisfactory
end_that_request_first understands partial completion of any size in
2.5, what more of a mid layer do you want?
> agreement can be reached then the current direction it is going will trash
> the Virtual DMA hardware coming in the future.
Is that so?
-- 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/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:52 EST