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
h...@suse.de                          +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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to