From: Thomas Gleixner <tglx@linutronix.de>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Waiman Long <longman@redhat.com>,
Srinivas Eeda <srinivas.eeda@oracle.com>,
kin.cho@oracle.com
Subject: Re: [PATCH] acpi_pm: Reduce PMTMR counter read contention
Date: Sun, 10 Feb 2019 22:08:53 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.1902102159070.8784@nanos.tec.linutronix.de> (raw)
In-Reply-To: <853e8cf6-aba9-0200-8e39-e362848399ba@oracle.com>
On Sat, 2 Feb 2019, Zhenzhong Duan wrote:
> On 2019/1/31 22:26, Thomas Gleixner wrote:
> > > > I'm not against the change per se, but I really want to understand
> > > > why we need all the complexity for something which should never be
> > > > used in a real world deployment.
> > > >
> > > Hmm, it's a strong word of "never be used". Customers may happen to
> > > use nohpet(sanity test?) and report bug to us. Sometimes they does
> > > report a bug that reproduce with their customed config. There may
> > > also be BIOS setting HPET disabled.
> >
> > And because the customer MAY do completely nonsensical things (and there
> > are a lot more than the HPET) the kernel has to handle all of them?
>
> Ok, then. I don't have more suggestion to convince you.
You give up too fast :)
The point is, that we really want proper justifications for changes like
this. Some 'may, could and more handwaving' simply does not cut it.
So if you can just describe a realistic scenario, which does not involve
thoughtless flipping of BIOS options, then this becomes way more palatable.
> I just think of a simple fix as below. I think it will work for both hpet
> and pmtmr. We will test it when the env is available.
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1353,6 +1353,7 @@ static int change_clocksource(void *data)
>
> write_seqcount_end(&tk_core.seq);
> raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
> + tick_clock_notify();
>
> return 0;
> }
> @@ -1371,7 +1372,6 @@ int timekeeping_notify(struct clocksource *clock)
> if (tk->tkr_mono.clock == clock)
> return 0;
> stop_machine(change_clocksource, clock, NULL);
> - tick_clock_notify();
> return tk->tkr_mono.clock == clock ? 0 : -1;
> }
This won't resolve the concurrency issues of HPET or PMTIMER in any
way. Instead it breaks the careful orchestrated mechanism of clocksource
change.
Thanks,
tglx
next prev parent reply other threads:[~2019-02-10 21:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 7:23 Zhenzhong Duan
2019-01-30 8:06 ` Thomas Gleixner
2019-01-31 3:50 ` Zhenzhong Duan
2019-01-31 14:26 ` Thomas Gleixner
2019-02-02 2:52 ` Zhenzhong Duan
2019-02-02 7:55 ` Kin Cho
2019-02-10 21:08 ` Thomas Gleixner [this message]
2019-02-18 3:48 ` Zhenzhong Duan
2019-02-28 3:33 ` Zhenzhong Duan
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=alpine.DEB.2.21.1902102159070.8784@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=kin.cho@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=srinivas.eeda@oracle.com \
--cc=x86@kernel.org \
--cc=zhenzhong.duan@oracle.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
all inboxes | Powered by JetHome®