[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a2f4e01-c9f5-4fb5-953e-2999e00a4b37@huaweicloud.com>
Date: Fri, 27 Sep 2024 16:08:26 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: tj@...nel.org, lizefan.x@...edance.com, hannes@...xchg.org,
longman@...hat.com, chenridong@...wei.com, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/3] workqueue: doc: Add a note saturating the
system_wq is not permitted
On 2024/9/26 20:49, Michal Koutný wrote:
> On Mon, Sep 23, 2024 at 11:43:51AM GMT, Chen Ridong <chenridong@...weicloud.com> 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
Powered by blists - more mailing lists