All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <pmladek@suse.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>,
	<lecopzer.chen@mediatek.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 v4 4/6] kernel/watchdog: Adapt the watchdog_hld interface for async model
Date: Thu, 26 May 2022 17:39:54 +0800	[thread overview]
Message-ID: <20220526093954.19319-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <YodhoxG0xmfrNYoN@alley>

> On Thu 2022-04-28 00:13:38, Lecopzer Chen wrote:
> > When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready
> > yet. E.g. on arm64, PMU is not ready until
> > device_initcall(armv8_pmu_driver_init).  And it is deeply integrated
> > with the driver model and cpuhp. Hence it is hard to push this
> > initialization before smp_init().
> > 
> > But it is easy to take an opposite approach and try to initialize
> > the watchdog once again later.
> > The delayed probe is called using workqueues. It need to allocate
> > memory and must be proceed in a normal context.
> > The delayed probe is able to use if watchdog_nmi_probe() returns
> > non-zero which means the return code returned when PMU is not ready yet.
> > 
> > Provide an API - retry_lockup_detector_init() for anyone who needs
> > to delayed init lockup detector if they had ever failed at
> > lockup_detector_init().
> > 
> > The original assumption is: nobody should use delayed probe after
> > lockup_detector_check() which has __init attribute.
> > That is, anyone uses this API must call between lockup_detector_init()
> > and lockup_detector_check(), and the caller must have __init attribute
> > 
> > --- a/kernel/watchdog.c
> > +++ b/kernel/watchdog.c
> > +/*
> > + * retry_lockup_detector_init - retry init lockup detector if possible.
> > + *
> > + * 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;
> > +
> > +	queue_work_on(__smp_processor_id(), system_wq, &detector_work);
> 
> Just a small nit. This can be simplified by calling:
> 
> 	schedule_work(&detector_work);
> 
> It uses "system_wq" that uses CPU-bound workers. It prefers
> the current CPU. But the exact CPU is not important. Any CPU-bound
> worker is enough.

Thanks!! I'll tweak this on -rc1
> 
> > +}
> > +
> 
> With the above change, feel free to use:
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>

Really appreciate your review and idea, thank you ver much.


BRs,
Lecopzer




WARNING: multiple messages have this Message-ID (diff)
From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <pmladek@suse.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>,
	<lecopzer.chen@mediatek.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 v4 4/6] kernel/watchdog: Adapt the watchdog_hld interface for async model
Date: Thu, 26 May 2022 17:39:54 +0800	[thread overview]
Message-ID: <20220526093954.19319-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <YodhoxG0xmfrNYoN@alley>

> On Thu 2022-04-28 00:13:38, Lecopzer Chen wrote:
> > When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready
> > yet. E.g. on arm64, PMU is not ready until
> > device_initcall(armv8_pmu_driver_init).  And it is deeply integrated
> > with the driver model and cpuhp. Hence it is hard to push this
> > initialization before smp_init().
> > 
> > But it is easy to take an opposite approach and try to initialize
> > the watchdog once again later.
> > The delayed probe is called using workqueues. It need to allocate
> > memory and must be proceed in a normal context.
> > The delayed probe is able to use if watchdog_nmi_probe() returns
> > non-zero which means the return code returned when PMU is not ready yet.
> > 
> > Provide an API - retry_lockup_detector_init() for anyone who needs
> > to delayed init lockup detector if they had ever failed at
> > lockup_detector_init().
> > 
> > The original assumption is: nobody should use delayed probe after
> > lockup_detector_check() which has __init attribute.
> > That is, anyone uses this API must call between lockup_detector_init()
> > and lockup_detector_check(), and the caller must have __init attribute
> > 
> > --- a/kernel/watchdog.c
> > +++ b/kernel/watchdog.c
> > +/*
> > + * retry_lockup_detector_init - retry init lockup detector if possible.
> > + *
> > + * 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;
> > +
> > +	queue_work_on(__smp_processor_id(), system_wq, &detector_work);
> 
> Just a small nit. This can be simplified by calling:
> 
> 	schedule_work(&detector_work);
> 
> It uses "system_wq" that uses CPU-bound workers. It prefers
> the current CPU. But the exact CPU is not important. Any CPU-bound
> worker is enough.

Thanks!! I'll tweak this on -rc1
> 
> > +}
> > +
> 
> With the above change, feel free to use:
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>

Really appreciate your review and idea, thank you ver much.


BRs,
Lecopzer




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <pmladek@suse.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>,
	<lecopzer.chen@mediatek.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 v4 4/6] kernel/watchdog: Adapt the watchdog_hld interface for async model
Date: Thu, 26 May 2022 17:39:54 +0800	[thread overview]
Message-ID: <20220526093954.19319-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <YodhoxG0xmfrNYoN@alley>

> On Thu 2022-04-28 00:13:38, Lecopzer Chen wrote:
> > When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready
> > yet. E.g. on arm64, PMU is not ready until
> > device_initcall(armv8_pmu_driver_init).  And it is deeply integrated
> > with the driver model and cpuhp. Hence it is hard to push this
> > initialization before smp_init().
> > 
> > But it is easy to take an opposite approach and try to initialize
> > the watchdog once again later.
> > The delayed probe is called using workqueues. It need to allocate
> > memory and must be proceed in a normal context.
> > The delayed probe is able to use if watchdog_nmi_probe() returns
> > non-zero which means the return code returned when PMU is not ready yet.
> > 
> > Provide an API - retry_lockup_detector_init() for anyone who needs
> > to delayed init lockup detector if they had ever failed at
> > lockup_detector_init().
> > 
> > The original assumption is: nobody should use delayed probe after
> > lockup_detector_check() which has __init attribute.
> > That is, anyone uses this API must call between lockup_detector_init()
> > and lockup_detector_check(), and the caller must have __init attribute
> > 
> > --- a/kernel/watchdog.c
> > +++ b/kernel/watchdog.c
> > +/*
> > + * retry_lockup_detector_init - retry init lockup detector if possible.
> > + *
> > + * 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;
> > +
> > +	queue_work_on(__smp_processor_id(), system_wq, &detector_work);
> 
> Just a small nit. This can be simplified by calling:
> 
> 	schedule_work(&detector_work);
> 
> It uses "system_wq" that uses CPU-bound workers. It prefers
> the current CPU. But the exact CPU is not important. Any CPU-bound
> worker is enough.

Thanks!! I'll tweak this on -rc1
> 
> > +}
> > +
> 
> With the above change, feel free to use:
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>

Really appreciate your review and idea, thank you ver much.


BRs,
Lecopzer




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-26  9:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 16:13 [PATCH v4 0/6] Support hld delayed init based on Pseudo-NMI for arm64 Lecopzer Chen
2022-04-27 16:13 ` Lecopzer Chen
2022-04-27 16:13 ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 1/6] kernel/watchdog: remove WATCHDOG_DEFAULT Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 2/6] kernel/watchdog: change watchdog_nmi_enable() to void Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 3/6] kernel/watchdog_hld: Ensure CPU-bound context when creating hardlockup detector event Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 4/6] kernel/watchdog: Adapt the watchdog_hld interface for async model Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-05-20  9:38   ` Petr Mladek
2022-05-20  9:38     ` Petr Mladek
2022-05-20  9:38     ` Petr Mladek
2022-05-26  9:39     ` Lecopzer Chen [this message]
2022-05-26  9:39       ` Lecopzer Chen
2022-05-26  9:39       ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 5/6] arm64: add hw_nmi_get_sample_period for preparation of lockup detector Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13 ` [PATCH v4 6/6] arm64: Enable perf events based hard " Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-04-27 16:13   ` Lecopzer Chen
2022-05-20  9:47   ` Petr Mladek
2022-05-20  9:47     ` Petr Mladek
2022-05-20  9:47     ` Petr Mladek
2022-05-26  9:35     ` Lecopzer Chen
2022-05-26  9:35       ` Lecopzer Chen
2022-05-26  9:35       ` Lecopzer Chen

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=20220526093954.19319-1-lecopzer.chen@mediatek.com \
    --to=lecopzer.chen@mediatek.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=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=pmladek@suse.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.