* [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
@ 2023-01-19 21:16 Tony Nguyen
2023-01-25 8:03 ` Andrysiak, Jakub
2023-01-26 16:10 ` Maciej Fijalkowski
0 siblings, 2 replies; 6+ messages in thread
From: Tony Nguyen @ 2023-01-19 21:16 UTC (permalink / raw)
To: intel-wired-lan
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
When both ice and the irdma driver are loaded, a warning
in check_flush_dependency is being triggered. This seems
to be because of the ice driver workqueue is allocated with
the WQ_MEM_RECLAIM flag, and the irdma one is not.
Looking at the kernel documentation, it doesn't seem like
the ice driver needs to use WQ_MEM_RECLAIM. Remove it.
Example trace:
[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[ +0.000161] [last unloaded: bonding]
[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[ +0.000003] Workqueue: ice ice_service_task [ice]
[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ +0.000002] PKRU: 55555554
[ +0.000003] Call Trace:
[ +0.000002] <TASK>
[ +0.000003] __flush_workqueue+0x203/0x840
[ +0.000006] ? mutex_unlock+0x84/0xd0
[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10
[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10
[ +0.000006] ? mutex_lock+0xa3/0xf0
[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]
[ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]
[ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]
[ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]
[ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[ +0.000059] ? up_write+0x5c/0x90
[ +0.000005] irdma_remove+0x36/0x90 [irdma]
[ +0.000062] auxiliary_bus_remove+0x32/0x50
[ +0.000007] device_release_driver_internal+0xfa/0x1c0
[ +0.000005] bus_remove_device+0x18a/0x260
[ +0.000007] device_del+0x2e5/0x650
[ +0.000005] ? __pfx_device_del+0x10/0x10
[ +0.000003] ? mutex_unlock+0x84/0xd0
[ +0.000004] ? __pfx_mutex_unlock+0x10/0x10
[ +0.000004] ? _raw_spin_unlock+0x18/0x40
[ +0.000005] ice_unplug_aux_dev+0x52/0x70 [ice]
[ +0.000160] ice_service_task+0x1309/0x14f0 [ice]
[ +0.000134] ? __pfx___schedule+0x10/0x10
[ +0.000006] process_one_work+0x3b1/0x6c0
[ +0.000008] worker_thread+0x69/0x670
[ +0.000005] ? __kthread_parkme+0xec/0x110
[ +0.000007] ? __pfx_worker_thread+0x10/0x10
[ +0.000005] kthread+0x17f/0x1b0
[ +0.000005] ? __pfx_kthread+0x10/0x10
[ +0.000004] ret_from_fork+0x29/0x50
[ +0.000009] </TASK>
Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt")
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
---
v4:
Change target to net
Update kernel splat
v3: added example trace
v2: fixed From tag
drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 031668698655..96c71bfec29d 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5537,7 +5537,7 @@ static int __init ice_module_init(void)
pr_info("%s\n", ice_driver_string);
pr_info("%s\n", ice_copyright);
- ice_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0, KBUILD_MODNAME);
+ ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME);
if (!ice_wq) {
pr_err("Failed to create workqueue\n");
return -ENOMEM;
--
2.38.1
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
2023-01-19 21:16 [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue Tony Nguyen
@ 2023-01-25 8:03 ` Andrysiak, Jakub
2023-01-26 16:10 ` Maciej Fijalkowski
1 sibling, 0 replies; 6+ messages in thread
From: Andrysiak, Jakub @ 2023-01-25 8:03 UTC (permalink / raw)
To: Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Tony Nguyen
> Sent: Thursday, January 19, 2023 10:16 PM
> To: intel-wired-lan@lists.osuosl.org
> Subject: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use
> WQ_MEM_RECLAIM flag for workqueue
>
> From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
>
> When both ice and the irdma driver are loaded, a warning in
> check_flush_dependency is being triggered. This seems to be because of the
> ice driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the
> irdma one is not.
>
> Looking at the kernel documentation, it doesn't seem like the ice driver
> needs to use WQ_MEM_RECLAIM. Remove it.
>
> Example trace:
>
> [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is
> flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000139] WARNING: CPU: 0
> PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
> [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE
> xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat
> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp
> llc rfkill vfat fat intel_rapl_msr intel _rapl_common isst_if_common skx_edac
> nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp
> kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel
> rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod
> target_ core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm
> iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core
> intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus
> intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c
> sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb
> crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash
> dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ +0.000161] [last
> unloaded: bonding]
> [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-
> rc2_next-queue-13jan-00458-gc20aabd57164 #1
> [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS
> SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ +0.000003] Workqueue:
> ice ice_service_task [ice] [ +0.000127] RIP:
> 0010:check_flush_dependency+0x178/0x1a0
> [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00
> 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be
> fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP:
> 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX:
> 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [
> +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI:
> ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112
> R09: ffffed117b306112 [ +0.000003] R10: ffff888bd983088b R11:
> ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00
> R14: ffff88810a3943ac R15: ffff888194bf3400 [ +0.000004] FS:
> 0000000000000000(0000) GS:ffff888bd9800000(0000)
> knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033 [ +0.000003] CR2: 000056035b208b60 CR3:
> 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0:
> 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [
> +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Call Trace:
> [ +0.000002] <TASK>
> [ +0.000003] __flush_workqueue+0x203/0x840 [ +0.000006] ?
> mutex_unlock+0x84/0xd0 [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10 [
> +0.000004] ? __pfx___flush_workqueue+0x10/0x10 [ +0.000006] ?
> mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190
> [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [
> +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ +0.000093]
> irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ?
> __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ?
> up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [
> +0.000062] auxiliary_bus_remove+0x32/0x50 [ +0.000007]
> device_release_driver_internal+0xfa/0x1c0
> [ +0.000005] bus_remove_device+0x18a/0x260 [ +0.000007]
> device_del+0x2e5/0x650 [ +0.000005] ? __pfx_device_del+0x10/0x10 [
> +0.000003] ? mutex_unlock+0x84/0xd0 [ +0.000004] ?
> __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ?
> _raw_spin_unlock+0x18/0x40 [ +0.000005] ice_unplug_aux_dev+0x52/0x70
> [ice] [ +0.000160] ice_service_task+0x1309/0x14f0 [ice] [ +0.000134] ?
> __pfx___schedule+0x10/0x10 [ +0.000006]
> process_one_work+0x3b1/0x6c0 [ +0.000008] worker_thread+0x69/0x670 [
> +0.000005] ? __kthread_parkme+0xec/0x110 [ +0.000007] ?
> __pfx_worker_thread+0x10/0x10 [ +0.000005] kthread+0x17f/0x1b0 [
> +0.000005] ? __pfx_kthread+0x10/0x10 [ +0.000004]
> ret_from_fork+0x29/0x50 [ +0.000009] </TASK>
>
> Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt")
> Signed-off-by: Anirudh Venkataramanan
> <anirudh.venkataramanan@intel.com>
> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> ---
> v4:
> Change target to net
> Update kernel splat
> v3: added example trace
> v2: fixed From tag
>
>
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Jakub Andrysiak <jakub.andrysiak@intel.com> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
2023-01-19 21:16 [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue Tony Nguyen
2023-01-25 8:03 ` Andrysiak, Jakub
@ 2023-01-26 16:10 ` Maciej Fijalkowski
2023-01-26 18:16 ` Anirudh Venkataramanan
2023-01-26 18:49 ` Jacob Keller
1 sibling, 2 replies; 6+ messages in thread
From: Maciej Fijalkowski @ 2023-01-26 16:10 UTC (permalink / raw)
To: Tony Nguyen; +Cc: intel-wired-lan
On Thu, Jan 19, 2023 at 01:16:08PM -0800, Tony Nguyen wrote:
> From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
>
> When both ice and the irdma driver are loaded, a warning
> in check_flush_dependency is being triggered. This seems
> to be because of the ice driver workqueue is allocated with
> the WQ_MEM_RECLAIM flag, and the irdma one is not.
>
> Looking at the kernel documentation, it doesn't seem like
> the ice driver needs to use WQ_MEM_RECLAIM. Remove it.
Can we have a better reasoning rather than 'it doesn't seem like ice
driver needs...' ?
Also, why was reclaim flag added in the first place?
>
> Example trace:
>
> [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
> [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
> [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
> in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
> _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
> 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
> core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
> ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
> acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
> ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
> [ +0.000161] [last unloaded: bonding]
> [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
> [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
> [ +0.000003] Workqueue: ice ice_service_task [ice]
> [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
> [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
> 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
> [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
> [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
> [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
> [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
> [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
> [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
> [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
> [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
> [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ +0.000002] PKRU: 55555554
> [ +0.000003] Call Trace:
> [ +0.000002] <TASK>
> [ +0.000003] __flush_workqueue+0x203/0x840
> [ +0.000006] ? mutex_unlock+0x84/0xd0
> [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10
> [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10
> [ +0.000006] ? mutex_lock+0xa3/0xf0
> [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]
> [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]
> [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]
> [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]
> [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
> [ +0.000059] ? up_write+0x5c/0x90
> [ +0.000005] irdma_remove+0x36/0x90 [irdma]
> [ +0.000062] auxiliary_bus_remove+0x32/0x50
> [ +0.000007] device_release_driver_internal+0xfa/0x1c0
> [ +0.000005] bus_remove_device+0x18a/0x260
> [ +0.000007] device_del+0x2e5/0x650
> [ +0.000005] ? __pfx_device_del+0x10/0x10
> [ +0.000003] ? mutex_unlock+0x84/0xd0
> [ +0.000004] ? __pfx_mutex_unlock+0x10/0x10
> [ +0.000004] ? _raw_spin_unlock+0x18/0x40
> [ +0.000005] ice_unplug_aux_dev+0x52/0x70 [ice]
> [ +0.000160] ice_service_task+0x1309/0x14f0 [ice]
> [ +0.000134] ? __pfx___schedule+0x10/0x10
> [ +0.000006] process_one_work+0x3b1/0x6c0
> [ +0.000008] worker_thread+0x69/0x670
> [ +0.000005] ? __kthread_parkme+0xec/0x110
> [ +0.000007] ? __pfx_worker_thread+0x10/0x10
> [ +0.000005] kthread+0x17f/0x1b0
> [ +0.000005] ? __pfx_kthread+0x10/0x10
> [ +0.000004] ret_from_fork+0x29/0x50
> [ +0.000009] </TASK>
>
> Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt")
> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> ---
> v4:
> Change target to net
> Update kernel splat
> v3: added example trace
> v2: fixed From tag
>
>
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 031668698655..96c71bfec29d 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5537,7 +5537,7 @@ static int __init ice_module_init(void)
> pr_info("%s\n", ice_driver_string);
> pr_info("%s\n", ice_copyright);
>
> - ice_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0, KBUILD_MODNAME);
> + ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME);
> if (!ice_wq) {
> pr_err("Failed to create workqueue\n");
> return -ENOMEM;
> --
> 2.38.1
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
2023-01-26 16:10 ` Maciej Fijalkowski
@ 2023-01-26 18:16 ` Anirudh Venkataramanan
2023-01-26 18:55 ` Jacob Keller
2023-01-26 18:49 ` Jacob Keller
1 sibling, 1 reply; 6+ messages in thread
From: Anirudh Venkataramanan @ 2023-01-26 18:16 UTC (permalink / raw)
To: intel-wired-lan
On 1/26/2023 8:10 AM, Maciej Fijalkowski wrote:
> On Thu, Jan 19, 2023 at 01:16:08PM -0800, Tony Nguyen wrote:
>> From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
>>
>> When both ice and the irdma driver are loaded, a warning
>> in check_flush_dependency is being triggered. This seems
>> to be because of the ice driver workqueue is allocated with
>> the WQ_MEM_RECLAIM flag, and the irdma one is not.
>>
>> Looking at the kernel documentation, it doesn't seem like
>> the ice driver needs to use WQ_MEM_RECLAIM. Remove it.
>
> Can we have a better reasoning rather than 'it doesn't seem like ice
> driver needs...' ?
The documentation for WQ_MEM_RECLAIM says this:
``WQ_MEM_RECLAIM``
All wq which might be used in the memory reclaim paths **MUST**
have this flag set. The wq is guaranteed to have at least one
execution context regardless of memory pressure.
The ice wq isn't used for memory reclamation, so this flag doesn't have
to be used.
> Also, why was reclaim flag added in the first place?
I don't know. This was probably a mistake to begin with, but it was
exposed only when the RDMA driver was also in use.
Ani
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
2023-01-26 18:16 ` Anirudh Venkataramanan
@ 2023-01-26 18:55 ` Jacob Keller
0 siblings, 0 replies; 6+ messages in thread
From: Jacob Keller @ 2023-01-26 18:55 UTC (permalink / raw)
To: intel-wired-lan
On 1/26/2023 10:16 AM, Anirudh Venkataramanan wrote:
> I don't know. This was probably a mistake to begin with, but it was
> exposed only when the RDMA driver was also in use.
>
> Ani
I replied on the other thread, but the short answer is that
create_singlethread_workqueue used to set it, and i40e migrated from
that to alloc_workqueue, and kept the same flags. The ice driver then
copied alloc_workqueue from the i40e implementation. Interestingly, the
out-of-tree i40e driver available on sourceforge has removed
WQ_MEM_RECLAIM but the in-kernel driver hasn't yet...
I suspect create_workqueue had it set originally because it was a
catch-all API at the time.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
2023-01-26 16:10 ` Maciej Fijalkowski
2023-01-26 18:16 ` Anirudh Venkataramanan
@ 2023-01-26 18:49 ` Jacob Keller
1 sibling, 0 replies; 6+ messages in thread
From: Jacob Keller @ 2023-01-26 18:49 UTC (permalink / raw)
To: intel-wired-lan
On 1/26/2023 8:10 AM, Maciej Fijalkowski wrote:
> On Thu, Jan 19, 2023 at 01:16:08PM -0800, Tony Nguyen wrote:
>> From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
>>
>> When both ice and the irdma driver are loaded, a warning
>> in check_flush_dependency is being triggered. This seems
>> to be because of the ice driver workqueue is allocated with
>> the WQ_MEM_RECLAIM flag, and the irdma one is not.
>>
>> Looking at the kernel documentation, it doesn't seem like
>> the ice driver needs to use WQ_MEM_RECLAIM. Remove it.
>
> Can we have a better reasoning rather than 'it doesn't seem like ice
> driver needs...' ?
>
> Also, why was reclaim flag added in the first place?
>
Yes. So this is caused by historical decision/accident. Way back in the
day we used to use create_singlethread_workqueue, which got converted to
alloc_workqueue by 6992a6c9c435 ("i40e: use alloc_workqueue instead of
create_singlethread_workqueue"). This conversion copied how
create_singlethread_workqueue set flags at the time:
> ee64e7f697ad Tejun Heo 2012-08-21 13:18 -0700 419│ #define create_singlethread_workqueue(name) \
> 23d11a58a9a6 Tejun Heo 2016-01-29 05:59 -0500 420│ alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
Since this was in i40e, when the development began on ice, it seems to
have simply copied what i40e did without regard for why the flag was set.
I suspect create_singlethread_workqueue set it because it was designed
to be a simple API that didn't expose flags so they added the reclaim
flag because the workqueue "might" need it.
My understanding of WQ_MEM_RECLAIM is that such work queues will still
execute when the system memory is low. Only work queues that must
execute in order to free resources ought to set it. (otherwise, if every
work queue sets it, it is basically the same as no work queue setting it...)
Hope this explanation helps.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-26 18:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-19 21:16 [Intel-wired-lan] [net-queue v4 1/1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue Tony Nguyen
2023-01-25 8:03 ` Andrysiak, Jakub
2023-01-26 16:10 ` Maciej Fijalkowski
2023-01-26 18:16 ` Anirudh Venkataramanan
2023-01-26 18:55 ` Jacob Keller
2023-01-26 18:49 ` Jacob Keller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox