FUJITA Tomonori wrote:
On Tue, 07 Aug 2007 12:13:41 -0500
Mike Christie <michaelc@xxxxxxxxxxx> wrote:
FUJITA Tomonori wrote:
Allocating 64K contiguous memory is not good so the next thing to do
is converting sg to use the sg chaining support fully. Or it might be
For LLDs like aic7xxx, I think we are stuck with a small
scsi_host_template->sg_tablesize, so to continue to get large requests
like before will we have to still allocate large segments?
No. sg.c has:
sizeof(struct scatterlist) * min(q->max_hw_segments, q->max_phys_segments)
If a lld has small max_hw_segments, it doesn't allocate big contiguous
memory.
Are we talking about the same thing? Are you saying that it does not
allocate big continuous memory for the scatterlist right? I was asking
about continuous memory for the buffer sg.c copies data to/from for the
IO operation. I was saying that currently for something like aic if we
want to continue to support 8 MB commands (or whatever it was) like
before, then because its sg_tablesize/max_hw_segments is so small we
have to continue allocating large IO buffers. That did not change right?
If so let me know because you save me :)
Is block/scsi_ioctl.c converted to sg chaining in any tree yet? Is that
in your tree or one of Jen's branches.
block/scsi_ioctl.c uses the standard block layer functions, there is
nothing to convert in it. sglist doesn't change the standard block
layer functions much since it doesn't allocate sg list. It changes
only blk_rq_map_sg.
Now only scsi-ml is changed to allocate chaining sg list
properly. Others like cciss are not converted yet, I think. It might
make sense to have the standard block layer functions to allocate
chaining sg list properly. So we could convert to potential consumers
(scsi-ml, sg, ccisss, etc) use them though I'm not sure how many non
scsi-ml needs chaining sg list.
For drivers like sg and st, do mean the the sg list that is passed to
functions like scsi_execute_async? If we kill that argument, and instead
have sg.c and other scsi_execute_async callers just call blk helpers
like blk_rq_map_user then we would not have to worry about drivers like
sg needing to know about chaining right? I mean sg.c would not every
interact with a scatterlist. It would just interact with a request and
the blk helpers map data for it. The scatterlist that sg and st interact
with is bogus. It gets thrown away in scsi_execute_async and is only
used for book keeping.
I think it would be best to either have drivers like sg and st use
blk_rq helpers to map data to requests like in my patches (this way they
never know about scatterlists), or have sg and st allocate and setup a
scatterlist properly and then just attach that to the request like we
did before (we would have to add back in those checks to scsi-ml to
check for that case again for this latter idea).
cciss is different right since it is doing blk_rq_map_sg and that
itself. I am not getting into that :)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
