James Bottomley wrote:
On Mon, 2006-02-06 at 11:54 -0600, Mike Christie wrote:
We actually need ths shost pointer becuase we do not represent the LU in
the kernel. So we go from:
scsi_host -> host's uspace request_queue (used to pass commands and
messages from the target LLD interrup handler to our netlink
code/userspace -> in userspace we represent the target, device/LU, and host.
Tomo did you add a virtual scsi_device somewhere?
OK, well, the problem is that struct scsi_cmnd is allocated in the
critical I/O path. The more elements it has, the more time it takes to
set up and tear down. Kenneth Chen of intel has already produced
figures showing that you can get measurable I/O improvement simply by
dropping fields from it, so I'm very, very reluctant to increase its
size.
I understand. To make this worse, for the target code since we are
mapping data like SG_IO block layer code (we used their functions) we
need process context for the unmap. To handle this we added a work
struct on the scsi_cmnd and the work struct is pretty large and only
used for targets. We can move all the target specific to a:
scsi_tgt_cmnd {
work;
host;
};
And store out scsi_tgt_cmnd in the scsi_cmnd->host_scribble or somewhere
on the SCp. Is that too hacky?
-
: 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
