| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87h7kafh2h.fsf@linux.ibm.com> Date: Tue, 13 Apr 2021 08:29:58 -0500 From: Nathan Lynch <nathanl@...ux.ibm.com> To: Lijun Pan <lijunp213@...il.com> Cc: netdev@...r.kernel.org Subject: Re: [PATCH net-next] ibmvnic: queue reset work in system_long_wq Hi Lijun, Lijun Pan <lijunp213@...il.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.
Powered by blists - more mailing lists