James Bottomley wrote:
On Thu, 2005-12-08 at 21:46 +0300, Vladislav Bolkhovitin wrote:
- Scst has some performance advantages over stgt, at least, on
hardware targets, because it allows internal handling in SIRQ context as
well as doesn't need user space program, so it eliminates additional
context switches (at least 3 per command for WRITEs and 2 per command
for reads plus switches to user space daemon, probably, 2 per command).
5 context switches per command looks too much for me, especially
considering how little work is done on each context. It means ~15000
CS/sec on regular 200Mb/sec link with 64K block size. Additionally,
kernel only commands execution allows direct access to page cache, which
is GREAT performance improvement, because in architecture with user
space daemon the data should be copied several times between kernel and
user space. Or, do I miimpss anything?
I do have to say that I consider operation in interrupt context (or even
kernel context) to be a disadvantage. Compared with the response times
that most arrays have to SCSI commands, the kernel context switch time
isn't that significant.
Additionally, it's perfectly possible for all of this to be done zero
copy on the data. A user space target mmaps the data on its storage
device and then does a SG_IO type scatter gather user virtual region
pass to the underlying target infrastructure. We already have this
demonstrated in the SG_IO path, someone just needs to come up with the
correct implementation for a target path.
I'm not completely understand how it will work. Consider, there are
READ/WRITE commands with random data sizes arrive from an initiator. Are
you going to do map/unmap for each command individually or alloc data
buffers for commands from a premapped area and live with possible its
fragmentation? If map/unmap individually, then I should say that those
are very expensive operations.
The great advantage of doing SCSI state machines in user space is that
you can prototype anything you want, and user space has much better
state machine implementation (and debugging) tools available than the
kernel does.
James
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Scst-devel mailing list
Scst-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/scst-devel
-
: 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
