[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdTXWrB8dascOIM_@slm.duckdns.org>
Date: Tue, 20 Feb 2024 06:46:18 -1000
From: Tejun Heo <tj@...nel.org>
To: Xuewen Yan <xuewen.yan@...soc.com>
Cc: jiangshanlai@...il.com, corbet@....net, paulmck@...nel.org,
rdunlap@...radead.org, peterz@...radead.org, yanjiewtw@...il.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
ke.wang@...soc.com, xuewen.yan94@...il.com
Subject: Re: [PATCH] workqueue: Control the frequency of intensive warning
through cmdline
Hello,
On Mon, Feb 19, 2024 at 03:46:34PM +0800, Xuewen Yan wrote:
> +#ifdef CONFIG_WQ_CPU_INTENSIVE_REPORT
> +static unsigned int wq_cpu_intensive_warning_per_count = 4;
> +module_param_named(cpu_intensive_warning_per_count, wq_cpu_intensive_warning_per_count, uint, 0644);
> +#endif
wq_cpu_intensive_warning_nth is probably shorter and more idiomatic.
> @@ -1202,7 +1206,7 @@ static void wq_cpu_intensive_report(work_func_t func)
> * exponentially.
> */
> cnt = atomic64_inc_return_relaxed(&ent->cnt);
> - if (cnt >= 4 && is_power_of_2(cnt))
> + if (wq_cpu_intensive_warning_per_count && !(cnt % wq_cpu_intensive_warning_per_count))
But aren't you mostly interested in the first report? Note that these events
can be very high frequency and reporting every nth event can lead to a lot
of constant warnings. Wouldn't it make sense to keep the exponential backoff
while allowing adjusting the initial threshold?
Thanks.
--
tejun
Powered by blists - more mailing lists