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 |
Context | Check | Description |
---|---|---|
netdev/apply | fail | Patch does not apply to net-next |
netdev/tree_selection | success | Clearly marked for net-next |
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 --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:
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(-)