SCSI RAM driver

This is the first release of a driver we've been using internally at Intel for a few weeks which is as low-latency as possible. It's designed to let us find latency issues elsewhere in the storage stack (eg filesystem, block layer, scsi layer)

There are a few different options, controlled through module parameters. The sector size and disc capacity are load-time parameters, but the parameters affecting performance are tweakable at runtime.

Arguably, this driver should be merged into scsi_debug. I didn't want to trip over Doug's toes while developing this driver, and the two drivers do have very different objectives. scsi_debug is obviously a lot more fully-featured and implements lots of bits of the spec I simply haven't bothered with. Like MODE SENSE ;-)

index a5f0aaa..e8dd685 100644
@@ -1499,6 +1499,16 @@ config SCSI_DEBUG
 	  information. This driver is primarily of use to those testing the
 	  SCSI and block subsystems. If unsure, say N.
 
+config SCSI_RAM
+	tristate "SCSI RAM-based host"
+	depends on SCSI
+	help
+	  This driver simulates a host adapter with one disc attached.
+	  The primary purpose of this driver is for performance testing
+	  of the fs/block/scsi stack; as such it attempts to simulate a
+	  disc which is as fast as RAM.  If you are unsure how to answer
+	  this question, say N.
+
 config SCSI_MESH
 	tristate "MESH (Power Mac internal SCSI) support"
 	depends on PPC32 && PPC_PMAC && SCSI

index 925c26b..95466d8 100644
@@ -133,6 +133,7 @@ obj-$(CONFIG_SCSI_ENCLOSURE)	+= ses.o
 
 # This goes last, so that "real" scsi devices probe earlier
 obj-$(CONFIG_SCSI_DEBUG)	+= scsi_debug.o
+obj-$(CONFIG_SCSI_RAM)		+= scsi_ram.o
 
 obj-$(CONFIG_SCSI_WAIT_SCAN)	+= scsi_wait_scan.o
 

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

I see that two drivers have very different objectives but if we add use_thread option to scsi_debug (we can do easily), it seems that scsi_debug can provide all the features that scsi_ram does.

If we clean up scsi_debug driver, can scsi_debug work as a nice scsi ram driver?

It's not just use_thread. It's also discard_read/discard_write. And scsi_ram has a different data storage model from scsi_debug -- scsi_debug simulates an arbitrarily sized disc by wrapping around some small (virtually) contiguous allocation of pages; scsi_ram actually allocates the amount of ram that it's told to. This can be solved with another module parameter, of course.

I'm in no way opposed to merging the two; it's a question of whether Doug will mind me doing some surgery on his driver.

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

scsi_debug has a similar option, fake_rw, which discards both read and write data.

IIRC, if virtual_gb option is set to zero, scsi_debug allocates the amount of ram that it's told to.

I think that there are only two different features between scsi_debug and scsi_ram.

The first one is the thread option, a kernel thread per device executes scsi commands. Adding the option to scsi_debug is not so difficult though scsi_debug could create a device in the queuecommand path so we need some modifications to scsi_debug to drop the host_lock in the path.

The second one is how to allocate memory for logical unit's contents. scsi_debug uses vmalloc so there is a limit to the capacity of a that scsi_debug can support. scsi_ram allocates multiple pages so there is no limit in scsi_ram. However, I think that we could live without this feature (but I'm happy to send a patch to convert scsi_debug to use scsi_ram's way if you want).

Architectures that we might want to use scsi_ram with (e.g., x86_64), vmalloc can allocate huge memory. The advantage of vmalloc, a continuous memory area, makes the driver simpler a bit (and it enables scsi_debug to use the APIs to copies data between a sglist and a buffer, which also works well for other LLDs).