On 10/02/2015 07:33 PM, Bart Van Assche wrote:
On 09/29/2015 03:47 AM, Hannes Reinecke wrote:
The 'activate_complete' function needs to be executed after
stpg has finished, so we can as well execute stpg synchronously
and call the function directly.
Hello Hannes,
Another patch in this series moves invocation of the STPG commands to
the context of a workqueue. The setup on which I have been testing this
patch series consists of an initiator system with four ports and a
target system with eight ports and 100 LUNs. As a result, 4*8*100=3200
/dev/sd* devices are created on the initiator system and monitored by
the scsi_dh_alua handler. How many kernel threads will be needed to
monitor all these paths concurrently and how much memory will be
required for all these kernel threads ? What if the number of LUNs would
be even higher, e.g. 1000 ? Sorry but because of scalability concerns my
preference is that the RTPG and STPG commands are invoked asynchronously.
The paths are not 'monitored' in the normal sense, ie the workqueue is
not always active. The workqueue items is active only if a state change
needs to be handled.
I doubt that the overall resource usage will increase here, as
originally we would need to execute '->activate' for every path.
With the new design we will be starting a workqueue item _per port group
and LUN_, which will run until the new state could be successfully
retrieved.
I have considered using an asynchronous implementation, but sadly
scsi_execute() and friends doesn't have an asynchronous version.
Also we would need to handle quite a substantial bulk of computation
from within an interrupt handler, which would make the operation
really tricky.
We should be doing some analysis here to figure out if there really is
an increased memory usage and if this would turn out to be an issue.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: 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
