On Wed, Mar 30, 2016 at 9:04 AM, Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
> On Mon, Mar 28, 2016 at 4:53 PM, Mike Christie <mchristi@xxxxxxxxxx> wrote:
>> On 03/28/2016 03:46 PM, Richard Sharpe wrote:
>>> Hi folks,
>>>
>>> We noticed recently while testing with large numbers of iSCSI
>>> connections that iscsid was going to heroic lengths to change the nice
>>> value of the iSCSI work queue to -20. It becomes very expensive with
>>> hundreds of connections.
>>>
>>> This small patch has the LLD do the work,
>>>
>>> Feedback welcome.
>
> [...]
>
>>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>>> index 6bffd91..abaefe1 100644
>>> --- a/drivers/scsi/libiscsi.c
>>> +++ b/drivers/scsi/libiscsi.c
>>> @@ -2615,9 +2615,11 @@ struct Scsi_Host *iscsi_host_alloc(struct scsi_host_template *sht,
>>> ihost = shost_priv(shost);
>>>
>>> if (xmit_can_sleep) {
>>> + int wq_flags = __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_HIGHPRI;
>>
>>
>> I do not think we need to or are supposed to be setting __WQ_LEGACY. It
>> looks like it was only to catch the case here
>
> Attached is a patch the removes that flag and also WQ_MEM_RECLAIM
> because none of the work items placed on the queue do allocations with
> GPF_KERNEL, as far as I can tell.
It turns out that my second patch is also wrong because we do need
WQ_MEM_RECLAIM on the workqueue.
However, the fact that no one has noticed this problem for a long time
(probably since the workqueue model was changed) suggests that it does
not matter that the iSCSI workqueue is not WG_HIGHPRI.
Internally, we are doing some measurements to see if it makes any difference.
I will report back with the results, probably in a few days.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
--
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
