[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a7399dd5-f332-4a0e-a0a3-fcc0ba7a20bb@huaweicloud.com>
Date: Tue, 8 Oct 2024 09:32:32 +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/30 20:50, Michal Koutný wrote:
> Hi.
>
> On Fri, Sep 27, 2024 at 04:08:26PM GMT, Chen Ridong <chenridong@...weicloud.com> wrote:
>> 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.
>
> It doesn't depend only on generating frequency (in Tetsuo's example with
> slow works, the "high" would only be 256/s) and accurate information is
> likely only empirical, thus I'd refine it further:
>
>> Note: If something may generate more than @max_active outstanding
>> work items (do stress test your producers), it may saturate a system
>> wq and potentially lead to deadlock. It should utilize its own
>> dedicated workqueue rather than the system wq.
>
> (besides @max_active reference, I also changed generic system_wq to
> system wq as the surrounding text seems to refer to any of the
> system_*wq)
>
> Michal
Thank you, Michal.
I took a week off.
I will update soon.
Best regards,
Ridong.
Powered by blists - more mailing lists