diff mbox series

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

Message ID 20210413083233.10479-1-lijunp213@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [net-next] ibmvnic: queue reset work in system_long_wq | expand

Checks

Context Check Description
netdev/apply fail Patch does not apply to net-next
netdev/tree_selection success Clearly marked for net-next

Commit Message

Lijun Pan April 13, 2021, 8:32 a.m. UTC
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 <nathanl@linux.ibm.com>
Signed-off-by: Lijun Pan <lijunp213@gmail.com>
---
 drivers/net/ethernet/ibm/ibmvnic.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Comments

Nathan Lynch April 13, 2021, 1:29 p.m. UTC | #1
Hi Lijun,

Lijun Pan <lijunp213@gmail.com> 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.
diff mbox series

Patch

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: