[lkml]   [2009]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC PATCHSET block] block: blk-map updates and API cleanup
Hello, all.

These patches are available in the following git tree but it's on top
of the previous blk-map-related-fixes patchset which needs some
updating, so this posting is just for review and comments. This
patchset needs to spend quite some time in RCs even if it gets acked
eventually, so definitely no .30 material. Please also note that I
haven't updated the comment about bio chaining violating queue limit,
so please ignore that part.

git:// blk-map;a=shortlog;h=blk-map

The goals of this patchset are

* Clean up and refactor blk/bio PC map API interface and

* Add blk_rq_map_kern_sg() so that in-kernel user can issue
multi-segment PC request. scsi_lib.c currently does this directly
by building rq itself.

* This is also in the general direction of making block layer
interface more strictk. For PC requests, users only get to deal
with requests and buffers.

This patchset uses sg list to pass multi-segment memory area into
blk_rq_map_kern_sg() and also uses sgl to simplify internal

Boaz Harrosh has some objections against both of them. For the
former, I can't really think of using anything other than sgl for the
API. For the second point, the use of sgl inside bio for map
implementation does add overhead for blk_rq_map_user*() calls because
it first maps to sgl and then gets interpreted to bvec. The reason
that sgl is used for implementation is because it has richer API,
mainly sg_mapping_iter.

So, it basically comes down to whether reducing the overhead of
alloc/copying and freeing sgl one more time for each SG_IO call is
worth the added complexity. I don't really think it will show up
anywhere but if this is a problem, switching over to bvec for internal
implementation wouldn't be too difficult although then copying back
and forth would require some hairy code. Also, please note that the
new code is more generic in that it can handle highpage io and
bouncing buffers without adding any special provision for them.

I think the root problem is that we really don't have a proper data
structure and API for handling in-kernel segments. iovec can't cover
high pages. sgl is currently the closest thing but it's fat due for
the dma mapping addresses. I think what we need to do is improve sgl
(sgt) such that it maintains separate lists for kernel segments and
DMA mappings and enable it to be linked, spliced, cloned or whatever,
so we don't have to re-map back and forth. Well, that's for another

This patchset contains the following 17 patches.


0001 is misc prep. 0002 improves sg_miter so that it can be used for
copying between sgls. 0003 update alignment checking during direct
mapping (I think this is correct because there's no other way for low
level drivers to express segment length requirement). 0004-0007
cleans up the code for future updates.

0008-0013 refactors map code and adds blk_rq_map_kern_sgl(). 0014
drops custom sg mapping in scsi_lib.c and make it use
blk_rq_map_kern_sgl(). 0015 kills now unused stuff including

0016-0017 removes duplicate parameters from API.

This patchset is on top of the current linux-2.6-block#for-linus[1] +
blk-map-related-fixes patchset[2].

block/blk-map.c | 216 ++----
block/bsg.c | 5
block/scsi_ioctl.c | 21
drivers/block/pktcdvd.c | 2
drivers/cdrom/cdrom.c | 2
drivers/mmc/host/sdhci.c | 4
drivers/scsi/device_handler/scsi_dh_alua.c | 2
drivers/scsi/device_handler/scsi_dh_emc.c | 2
drivers/scsi/device_handler/scsi_dh_rdac.c | 2
drivers/scsi/scsi_lib.c | 113 ---
drivers/scsi/scsi_tgt_lib.c | 3
drivers/scsi/sg.c | 8
drivers/scsi/st.c | 3
fs/bio.c | 980 +++++++++++++++--------------
include/linux/bio.h | 170 ++---
include/linux/blkdev.h | 23
include/linux/scatterlist.h | 11
lib/scatterlist.c | 49 +
18 files changed, 806 insertions(+), 810 deletions(-)



[1] 714ed0cf62319b14dc327273a7339a9a199fe046

 \ /
  Last update: 2009-04-01 15:49    [W:0.154 / U:0.176 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site