On 05/11/2015 03:49 PM, Christoph Hellwig wrote: > On Mon, May 04, 2015 at 02:42:20PM +0200, Hannes Reinecke wrote: >> The current ALUA device_handler has two drawbacks: >> - We're sending a 'SET TARGET PORT GROUP' command to every LUN, >> disregarding the fact that several LUNs might be in a port group >> and will be automatically switched whenever _any_ LUN within >> that port group receives the command. >> - Whenever a LUN is in 'transitioning' mode we cannot block I/O >> to that LUN, instead the controller has to abort the command. >> This leads to increased traffic across the wire and heavy load >> on the controller during switchover. >> >> With this patch the RTPG handling is moved to a workqueue, which >> is being run once per port group. This reduces the number of >> 'REPORT TARGET PORT GROUP' and 'SET TARGET PORT GROUPS' which >> will be send to the controller. It also allows us to block >> I/O to any LUN / port group found to be in 'transitioning' ALUA >> mode, as the workqueue item will be requeued until the controller >> moves out of transitioning. > > I'm having a hard time understanding the workqueue use here. > What is the benefit of that one worker function to do everything? > It seems having a work struct in struct alua_queue_data to just > run STPG, and a different one to run RPTG in the port group structure > would be more sensible instead of interwinding them. > Hmm. It _might_ be possible. However, we need to serialize STPG and RTPG against each other; not sure if that's still possible when using different workqueue items. > Also why do you need the sigle threaded workqueue? That seems > like a possible limiting factor in a large enough system having > to deal with a cable disconnect cutting off multiple port groups, > or just during bootup. > Okay, will be switching to a normal workqueue. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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
