On 6/4/20 6:08 PM, Douglas Gilbert wrote:
The scsi_device structure seems to be carrying around a lot of baggage.
Assuming the object needs to be present on the SCSI fast path then
making it smaller will help in fitting one or several of them in cache
lines.
Now the effort to use xarrays is helping, but only in the order 32 bytes
at the moment. Currently we have pointers to the standard inquiry response
and several VPD pages with more VPD pages to come, I suspect.
So what about having a secondary scsi_device object (with a more
descriptive name) for all those parts of the currect scsi_device
object that aren't needed for the fast path? The secondary object
could be created in scsi_alloc_sdev() and pointed to by the
primary object (and vice versa). Then adding more context info
(e.g. more VPD pages) will not burden the fast path.
sizeof(struct scsi_device)=1976 bytes!
Comments?
Not sure if that's worth it.
What is far more pressing is a _real_ scsi device rescan, ie the
possibility of the scsi device changing its inquiry data upon rescan.
At this time the inquiry data is essentially frozen, and the only way to
handle this is to remove the device and rescan everything
(scsi-rescan-bus.sh -r ...).
It would far better if we could just issue a rescan and the scsi core
would detect the change internally without the need to recreate the
object itself.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
