On 02/14/2014 07:21 PM, Mike Christie wrote: > On 2/14/14 5:37 AM, Bart Van Assche wrote: [ .. ] >> I think this will only be sufficient if there are more CPU threads >> available than the number of LUNs for which an STPG has to be issued. > > Ah shoot, you reminded me of some other issue. With the above > command we only can do 1 unit of work at a time. With the > alloc_workqueue example I sent in the other mail, I think it would > create a new problem. > > alloc_workqueue with max_active=0 looks like it has the wq code > dynamically create worker threads as needed, so with that we could > end up with a lot of threads and can failover lots of devices (512 > with the current max) in parallel. The threads will even get reaped > when they are not needed. However, trying to create lots of threads > at failover time might have issues, and in general creating 32 or 64 > threads or more is probably not something we want to do. Another followup: Mike is, as usual, right. I need to use 'alloc_workqueue' to be able to have more than one worker at a time. And also Bart is right in that it makes sense to have STPG run asynchronously. However, in doing so I'll be bunching together STPG activations from several request_queues, and will be deferring I/O on those queues during STPG update. So to avoid stalled I/O I'll need to kick each of the queues again after STPG is finished, right? Hmm. Let's see how this will look like. 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
