RFC: split struct scsi_device in two

RFC: split struct scsi_device in two

[Douglas Gilbert]

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?

Doug Gilbert

Re: RFC: split struct scsi_device in two

[Hannes Reinecke]

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@suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer