From: Will Deacon <will@kernel.org>
To: yunhui cui <cuiyunhui@bytedance.com>
Cc: akpm@linux-foundation.org, alex@ghiti.fr, anup@brainfault.org,
aou@eecs.berkeley.edu, atish.patra@linux.dev,
catalin.marinas@arm.com, dianders@chromium.org,
johannes@sipsolutions.net, lihuafei1@huawei.com,
mark.rutland@arm.com, masahiroy@kernel.org, maz@kernel.org,
mingo@kernel.org, nicolas.schier@linux.dev, palmer@dabbelt.com,
paul.walmsley@sifive.com, suzuki.poulose@arm.com,
thorsten.blum@linux.dev, wangjinchao600@gmail.com,
yangyicong@hisilicon.com, zhanjie9@hisilicon.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [External] Re: [PATCH v4 1/2] watchdog: move arm64 watchdog_hld into common code
Date: Fri, 7 Nov 2025 13:10:47 +0000 [thread overview]
Message-ID: <aQ3v15yrm9JaWgrm@willie-the-truck> (raw)
In-Reply-To: <CAEEQ3wk5Ru4-=4Ecnc6kQAAbR57806xxYTz0o1z4KfgZE6Cg6w@mail.gmail.com>
On Fri, Nov 07, 2025 at 10:42:25AM +0800, yunhui cui wrote:
> On Mon, Nov 3, 2025 at 9:44 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Tue, Oct 14, 2025 at 11:14:24AM +0800, Yunhui Cui wrote:
> > > @@ -306,3 +307,85 @@ void __init hardlockup_config_perf_event(const char *str)
> > > wd_hw_attr.type = PERF_TYPE_RAW;
> > > wd_hw_attr.config = config;
> > > }
> > > +
> > > +#ifdef CONFIG_WATCHDOG_PERF_ADJUST_PERIOD
> > > +/*
> > > + * Safe maximum CPU frequency in case a particular platform doesn't implement
> > > + * cpufreq driver. Although, architecture doesn't put any restrictions on
> > > + * maximum frequency but 5 GHz seems to be safe maximum given the available
> > > + * CPUs in the market which are clocked much less than 5 GHz. On the other
> > > + * hand, we can't make it much higher as it would lead to a large hard-lockup
> > > + * detection timeout on parts which are running slower (eg. 1GHz on
> > > + * Developerbox) and doesn't possess a cpufreq driver.
> > > + */
> > > +#define SAFE_MAX_CPU_FREQ 5000000000UL // 5 GHz
> > > +__weak u64 hw_nmi_get_sample_period(int watchdog_thresh)
> > > +{
> > > + unsigned int cpu = smp_processor_id();
> > > + unsigned long max_cpu_freq;
> > > +
> > > + max_cpu_freq = cpufreq_get_hw_max_freq(cpu) * 1000UL;
> > > + if (!max_cpu_freq)
> > > + max_cpu_freq = SAFE_MAX_CPU_FREQ;
> > > +
> > > + return (u64)max_cpu_freq * watchdog_thresh;
> > > +}
> >
> > Why does this function become __weak? Neither arm64 nor riscv override
> > it afaict.
>
> Would you say there’s any particular issue here? If some architectures
> might need to override the hw_nmi_get_sample_period() function later
> on, wouldn’t __weak be a more reasonable choice?
__weak is pretty brittle (it can depend on link order if you have multiple
targets) and I suspect it prevents inlining when LTO isn't enabled. It's
cleaner and more robust for architectures to provide their hooks by
#defining the symbol, as is done commonly in other parts of the kernel.
But in this particular case, it's completely unnecessary because there
isn't an architectural override and so this function should simply be
static.
Will
next prev parent reply other threads:[~2025-11-07 13:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 3:14 [PATCH v4 0/2] Add HARDLOCKUP_DETECTOR_PERF support for RISC-V Yunhui Cui
2025-10-14 3:14 ` [PATCH v4 1/2] watchdog: move arm64 watchdog_hld into common code Yunhui Cui
2025-11-03 13:44 ` Will Deacon
2025-11-07 2:42 ` [External] " yunhui cui
2025-11-07 13:10 ` Will Deacon [this message]
2025-11-11 7:15 ` yunhui cui
2025-10-14 3:14 ` [PATCH v4 2/2] riscv: add HARDLOCKUP_DETECTOR_PERF support Yunhui Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQ3v15yrm9JaWgrm@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=cuiyunhui@bytedance.com \
--cc=dianders@chromium.org \
--cc=johannes@sipsolutions.net \
--cc=lihuafei1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=suzuki.poulose@arm.com \
--cc=thorsten.blum@linux.dev \
--cc=wangjinchao600@gmail.com \
--cc=yangyicong@hisilicon.com \
--cc=zhanjie9@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox