On 02/03/2014 01:08 PM, Junichi Nomura wrote:
> On 02/03/14 17:18, Hannes Reinecke wrote:
>> We only need to take care to add a small delay when calling
>> __pg_init_all_paths() to move processing off to a workqueue;
>> pg_init_done() is run from an interrupt context and needs to
>> complete as fast as possible.
> ...
>> @@ -1217,9 +1185,11 @@ static void pg_init_done(void *data, int errors)
>>
>> if (!m->pg_init_required)
>> m->queue_io = 0;
>> -
>> - m->pg_init_delay_retry = delay_retry;
>> - queue_work(kmultipathd, &m->process_queued_ios);
>> + else {
>> + m->pg_init_delay_retry = delay_retry;
>> + __pg_init_all_paths(m, 50/HZ);
>> + goto out;
>> + }
>>
>
> I forgot to comment on this.
> Adding delay to queue_work() doesn't make it fast.
> So I couldn't see why this "50/HZ" delay has to be added
> and where this value comes.
>
Well, it wasn't probably the best choice of words.
Thing is, without a delay the workqueue item will be executed
directly (cf __queue_delayed_work()).
But pg_init_done() is run from an interrupt context, and as such any
memory allocations have to be atomic.
So if we were to call queue_delayed_work() without any delay
we will end up calling scsi_dh_activate from an interrupt context,
too, but there we most definitely do _not_ have only atomic allocations.
Hence the delay.
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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
