From: Petr Mladek <pmladek@suse.com>
To: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: acme@kernel.org, akpm@linux-foundation.org,
alexander.shishkin@linux.intel.com, catalin.marinas@arm.com,
davem@davemloft.net, jolsa@redhat.com, jthierry@redhat.com,
keescook@chromium.org, kernelfans@gmail.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-perf-users@vger.kernel.org, mark.rutland@arm.com,
masahiroy@kernel.org, matthias.bgg@gmail.com, maz@kernel.org,
mcgrof@kernel.org, mingo@redhat.com, namhyung@kernel.org,
nixiaoming@huawei.com, peterz@infradead.org,
sparclinux@vger.kernel.org, sumit.garg@linaro.org,
wangqing@vivo.com, will@kernel.org, yj.chiang@mediatek.com
Subject: Re: [PATCH v3 5/5] arm64: Enable perf events based hard lockup detector
Date: Thu, 28 Apr 2022 10:27:32 +0200 [thread overview]
Message-ID: <YmpP9PTa1/pSmuuQ@alley> (raw)
In-Reply-To: <20220426163840.18871-1-lecopzer.chen@mediatek.com>
On Wed 2022-04-27 00:38:40, Lecopzer Chen wrote:
> > What about just introducing the API that will allow to try to
> > initialize the hardlockup detector later:
> >
> > /*
> > * Retry hardlockup detector init. It is useful when it requires some
> > * functionality that has to be initialized later on a particular
> > * platform.
> > */
> > void __init retry_lockup_detector_init(void)
> > {
> > /* Must be called before late init calls. */
> > if (!allow_lockup_detector_init_retry)
> > return 0;
> >
> > queue_work_on(__smp_processor_id(), system_wq, &detector_work);
> > }
> >
> > /*
> > * Ensure that optional delayed hardlockup init is proceed before
> > * the init code and memory is freed.
> > */
> > static int __init lockup_detector_check(void)
> > {
> > /* Prevent any later retry. */
> > allow_lockup_detector_init_retry = false;
> >
> > /* Make sure no work is pending. */
> > flush_work(&detector_work);
> > }
> > late_initcall_sync(lockup_detector_check);
> >
> > You could leave lockup_detector_init() as it is. It does not really
> > matter what was the exact error value returned by watchdog_nmi_probe().
> >
> > Then you could call retry_lockup_detector_init() in
> > armv8_pmu_driver_init() and be done with it.
> >
> > It will be universal API that might be used on any architecture
> > for any reason. If nobody calls retry_lockup_detector_init()
> > then nohing will happen and the code will work as before.
> >
> > It might make sense to provide the API only on architectures that
> > really need it. We could hide it under
> >
> > ARCH_NEED_DELAYED_HARDLOCKUP_DETECTOR_INIT
> >
> > , similar to ARCH_NEEDS_CPU_IDLE_COUPLE.
> >
>
> During implementation, if I add ARCH_NEED_DELAYED_..., there will contain
> many enclosed ifdef-endif and is a little bit ugly.
> Also, I didn't find a must-have reason to this Kconfig after I rebase from
> your suggestion.
>
> The one calls retry_lockup_detector_init() must fail at lockup_detector_init,
> so I think anyone who has aleady failed at lockup_detector_init() has right
> to retry no matter HW, SW or Arch reason.
> Thus I might not introduce a new Kconfig in v4, and I would be glad to see
> if any further commet on this.
Sounds reasonable from my POV. There is not much code. It will be removed
after the init phase. It will be most likely removed even during
compilation when linked with gcc LTE optimization and the symbols
are not used.
Best Regards,
Petr
PS: It might take few days until I do the review of v4. I am a bit
overloaded at the moment.
prev parent reply other threads:[~2022-04-28 8:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 14:14 [PATCH v3 0/5] Support hld delayed init based on Pseudo-NMI for arm64 Lecopzer Chen
2022-03-24 14:14 ` [PATCH v3 1/5] kernel/watchdog: remove WATCHDOG_DEFAULT Lecopzer Chen
2022-03-24 14:14 ` [PATCH v3 2/5] kernel/watchdog: change watchdog_nmi_enable() to void Lecopzer Chen
2022-03-24 14:14 ` [PATCH v3 3/5] kernel/watchdog_hld: Ensure CPU-bound context when creating hardlockup detector event Lecopzer Chen
2022-03-24 14:14 ` [PATCH v3 4/5] kernel/watchdog: Adapt the watchdog_hld interface for async model Lecopzer Chen
2022-04-04 14:41 ` Petr Mladek
2022-04-05 13:35 ` Lecopzer Chen
2022-04-05 15:19 ` Petr Mladek
2022-04-07 16:21 ` Lecopzer Chen
2022-03-24 14:14 ` [PATCH v3 5/5] arm64: Enable perf events based hard lockup detector Lecopzer Chen
2022-04-04 14:17 ` Petr Mladek
2022-04-05 12:53 ` Lecopzer Chen
2022-04-05 14:36 ` Petr Mladek
2022-04-07 16:59 ` Lecopzer Chen
2022-04-13 10:25 ` Petr Mladek
2022-04-21 16:30 ` Lecopzer Chen
2022-04-26 16:38 ` Lecopzer Chen
2022-04-28 8:27 ` Petr Mladek [this message]
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=YmpP9PTa1/pSmuuQ@alley \
--to=pmladek@suse.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=jolsa@redhat.com \
--cc=jthierry@redhat.com \
--cc=keescook@chromium.org \
--cc=kernelfans@gmail.com \
--cc=lecopzer.chen@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=maz@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=nixiaoming@huawei.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=sumit.garg@linaro.org \
--cc=wangqing@vivo.com \
--cc=will@kernel.org \
--cc=yj.chiang@mediatek.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;
as well as URLs for NNTP newsgroup(s).