RFC: sg driver addition: SG_FLAG_SHARED_MMAP_IO

I mentioned this idea a few weeks ago on this list: namely to allow a sg pass-through request to use the mmap-ed reserve buffer associated with another sg file descriptor.

In my experience mmap-ed IO using sg's reserve buffer mapped into the user space is faster than direct IO schemes. However one shortcoming is that if you try to copy between two devices using this technique then you end up with two separate mmap-ed buffers in the user space program. Then the user space program needs to copy between the two buffers which would defeat much of the advantage of the mmap-ed IO. You could (and sgm_dd in sg3_utils does) use mmap-ed IO on the read side and direct IO on the write side (or vice versa).

I used the sg driver as found in lk 2.6.21-rc4 as a baseline (and I don't think sg has changed since 2.6.19). A gzipped diff is attached. There is also some test code (a modified sgm_dd) in the sg3_utils-1.24 beta on the www.torque.net/sg site.

Here is an example of a disk to disk copy:
sgm_dd if=/dev/sg0 of=/dev/sg1 oflag=smmap bs=512

The new flag is 'oflag=smmap' which instructs the write SG_IO on /dev/sg1 to set SG_FLAG_SHARED_MMAP_IO and it passes the mmap-ed buffer used for /dev/sg0 in dxferp. [Add a 'verbose=1' option and it will indicate how many times shared mmap IO was requested and how many times it was actually done.]

Features:
- allow both side of a copy like operation to dma into and out of the same user space buffer
- minimal per command overhead (i.e. building of scatter gather lists and pinning pages)
- could copy a single source to multiple destinations efficiently
- if shared reserve buffer unavailable (or not big enough) then fall back to indirect IO transparently
- new info bit SG_INFO_SHARED_MMAP_IO indicates whether shared mmap-ed IO was done

Restrictions (enforced by the sg driver):
- confined to file descriptors in the same process
- there can be only one user of a reserve buffer at a time
- low_dma is honoured

Complexity
- it does have a few more corner cases than usual. For example in above sgm_dd invocation: closing /dev/sg0 while /dev/sg1 is sharing its mmap-ed reserve buffer ...

Here are some timings copying between two ramdisks. It is assumed the 'bs=8k' given to dd is equivalent to 'bs=512 bpt=16' given to sgm_dd.

# lsscsi -g
[4:0:0:0]    disk    Linux    scsi_debug       1.82  /dev/sda  /dev/sg0
[5:0:0:0]    disk    Linux    scsi_ses         1.06  /dev/sdb  /dev/sg1

# ./dd_tsts.sh
Usage: dd_tsts.sh <ifile> <ofile> <times> <bs>

# ./dd_tsts.sh /dev/sda /dev/sdb 50 8k
Indirect IO with dd
dd if=/dev/sda of=/dev/sdb bs=8k
real    0m7.448s
user    0m0.080s
sys     0m7.046s

Direct IO with dd
dd if=/dev/sda iflag=direct of=/dev/sdb oflag=direct bs=8k

real    0m4.529s
user    0m0.114s
sys     0m3.799s

# ./sg_dd_tsts.sh /dev/sg0 /dev/sg1 50 16
Indirect IO with sg_dd
sg_dd if=/dev/sg0 of=/dev/sg1 bs=512 bpt=16
real    0m6.304s
user    0m0.171s
sys     0m5.268s

Direct IO with sg_dd
sg_dd if=/dev/sg0 iflag=dio of=/dev/sg1 oflag=dio bs=512 bpt=16

real    0m4.246s
user    0m0.135s
sys     0m3.395s

Mmap read, indirect IO write with sgm_dd
sgm_dd if=/dev/sg0 of=/dev/sg1 bs=512 bpt=16

real    0m4.023s
user    0m0.127s
sys     0m3.259s

Mmap read, direct IO write with sgm_dd
sgm_dd if=/dev/sg0 of=/dev/sg1 oflag=dio bs=512 bpt=16

real    0m4.057s
user    0m0.164s
sys     0m3.264s

Mmap read, shared mmap write with sgm_dd
sgm_dd if=/dev/sg0 of=/dev/sg1 oflag=smmap bs=512 bpt=16

real    0m3.871s
user    0m0.131s
sys     0m3.111s

Don't expect drastic improvements in real IO unless it is in the gigabyte per second range.

Doug Gilbert

on question; does your patch also make the block layer sg support this? And if not, why not? (I would think sg and block layer sg should converge not diverge)

(I would look but your attachement is gzipd for some reason)

if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org