[PATCH net-next] ibmvnic: queue reset work in system_long_wq

When the linux system is under stress or the VIOS server is
responding slowly, the vnic driver may hit multiple timeouts during the
reset process. Instead of queueing the reset requests to system_wq,
queueing the relatively slow reset job to the system_long_wq.

Suggested-by: Nathan Lynch <redacted>
Signed-off-by: Lijun Pan <redacted>
---
 drivers/net/ethernet/ibm/ibmvnic.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 3773dc97e63d..bbe45063b443 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c

@@ -2243,8 +2243,9 @@ static void __ibmvnic_reset(struct work_struct *work)
 	adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);
 
 	if (test_and_set_bit_lock(0, &adapter->resetting)) {
-		schedule_delayed_work(&adapter->ibmvnic_delayed_reset,
-				      IBMVNIC_RESET_DELAY);
+		queue_delayed_work(system_long_wq,
+				   &adapter->ibmvnic_delayed_reset,
+				   IBMVNIC_RESET_DELAY);
 		return;
 	}
 

@@ -2386,7 +2387,7 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
 	rwi->reset_reason = reason;
 	list_add_tail(&rwi->list, &adapter->rwi_list);
 	netdev_dbg(adapter->netdev, "Scheduling reset (reason %d)\n", reason);
-	schedule_work(&adapter->ibmvnic_reset);
+	queue_work(system_long_wq, &adapter->ibmvnic_reset);
 
 	ret = 0;
 err:

-- 
2.23.0

Hi Lijun,

Lijun Pan [off-list ref] writes:

When the linux system is under stress or the VIOS server is
responding slowly, the vnic driver may hit multiple timeouts during the
reset process. Instead of queueing the reset requests to system_wq,
queueing the relatively slow reset job to the system_long_wq.

I think the commit message should better justify the change. I suggested
this because the reset process for ibmvnic commonly takes multiple
seconds, clearly making it inappropriate for schedule_work/system_wq:

(workqueue.h)
 * system_wq is the one used by schedule[_delayed]_work[_on]().
 * Multi-CPU multi-threaded.  There are users which expect relatively
 * short queue flush time.  Don't queue works which can run for too
 * long.
...
 * system_long_wq is similar to system_wq but may host long running
 * works.  Queue flushing might take relatively long.

If the reset process isn't completing before some kind of deadline (is
this the nature of the timeouts you mention?), changing to
system_long_wq is unlikely to help that. The reason to make this change
is that ibmvnic's use of the default system-wide workqueue for a
relatively long-running work item can negatively affect other workqueue
users.