On 2024/9/26 20:49, Michal Koutný wrote:
On Mon, Sep 23, 2024 at 11:43:51AM GMT, Chen Ridong <chenridong@xxxxxxxxxxxxxxx> wrote:
+ Note: If something is expected to generate a large number of concurrent
+ works, it should utilize its own dedicated workqueue rather than
+ system wq. Because this may saturate system_wq and potentially lead
+ to deadlock.
How does "large number of concurrent" translate practically?
The example with released cgroup_bpf from
cgroup_destroy_locked
cgroup_bpf_offline
which is serialized under cgroup_mutex as argued previously. So this
generates a single entry at a time and it wouldn't hint towards the
creation of cgroup_bpf_destroy_wq.
I reckon the argument could be something like the processing rate vs
production rate of entry items should be such that number of active
items is bound. But I'm not sure it's practical since users may not know
the comparison result and they would end up always creating a dedicated
workqueue.
Michal
Thank you, Michal.
I think it's difficult to measure the comparison result. Actually, if
something generates work at a high frequency, it would be better to use
dedicated wq.
How about:
Note: If something may generate works frequently, it may saturate the
system_wq and potentially lead to deadlock. It should utilize its own
dedicated workqueue rather than system wq.
Best regards,
Ridong
