On 05/12/2015 10:16 AM, Christoph Hellwig wrote: > So how about the following idea for GTPG and STPG handling: > > - we keep a single thread workqueue, but per target group instead > of global to avoid concurrency issues hitting us too badly, after > all workqueues are cheap these days. Okay. > - GTPG keeps the per-group work_item, but instead of the separate > lsit for STPG we just add the work item to the alua_queue_data > structure, which at the point might also get a new name relecting > the use a bit better. STPG remains synchronous. > Well, I don't think that'll work. qdata is per sdev, and STPG is per port group. While it's true that we need to run STPG once a qdata item has been created, it's not necessarily true that we need to run STPG for _every_ qdata item; if we have more than one path per group we need to run STPG only for one of them. (Which is why there is a qdata structure in the first place.) What I can do, though, is to split off stpg and rtpg in two different routines, each with its own workqueue item. That way the actual implementation becomes easier to follow. 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
