linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Chen Yu <yu.c.chen@intel.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>, Ingo Molnar <mingo@kernel.org>,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed
Date: Tue, 14 Mar 2017 18:38:03 +0100	[thread overview]
Message-ID: <20170314173803.GA17126@amd> (raw)
In-Reply-To: <20170219043718.GA4953@yu-desktop-1.sh.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

Hi!

> > > However there are still three problems left:
> > > 1. More and more reports show that other platforms also
> > >    encountered the same issue, so the quirk list might
> > >    be endless.
> > > 2. Each CPUs should take the save/restore operation into
> > >    consideration, rather than the boot CPU alone.
> > > 3. Normally ACPI T-state re-evaluation is done on resume,
> > >    however there is no _TSS on the bogus platform, thus
> > >    above re-evaluation code does not run on that machine.
> > > 
> > > Solution:
> > > This patch is based on the fact that, we generally should not
> > > expect the system to come back from resume with throttling
> > > enabled, but leverage the OS components to deal with it,
> > > such as thermal event. So we simply clear the MSR T-state
> > > and print the warning if it is found to be enabled after
> > > resumed back. Besides, we can remove the quirk in previous patch
> > > later.
> > 
> > What if the machine _is_ hot? 
> > 
> Later the linux has a chance to adjust the tstate if the system is too hot,
> with the help of thermal framework.

Will it adjust the tstate? Normally, we do such stuff when tresholds
are exceeded. If we are already above the threshold, we'll see no
reason to 

> But if the cpu is not inside any thermal zone, then there is no way for the
> OS to adjust the tstate after resume, however in this case I think it is up
> to the user space to adjust the tstate msr, for example, by using thermald
> daemon to bind the cpu to the thermal zone.

Umm. Userland should not access MSRs. And we certainly should not
depend on userland adjusting the MSRs!

> > Should we introduce generic framework to "fix" all the cpus? Actually,
> > should this be done right on cpu hotplug?
> Do you mean, fix other MSR-inconsistent issues, not only the tstate MSR?
> Currently the tstate re-adjusting is invoked in cpuhotplug notifier
> after each nonboot cpus are brought up:
> acpi_soft_cpu_online -> acpi_processor_reevaluate_tstate -> adjust_tstate_msr

Ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-03-14 17:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17  8:27 [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed Chen Yu
2017-02-18  9:02 ` Pavel Machek
2017-02-19  4:37   ` Chen Yu
2017-03-14 17:38     ` Pavel Machek [this message]
2017-03-15 15:11       ` Chen Yu
2017-03-13 22:41 ` Rafael J. Wysocki
2017-03-15 14:43   ` Chen Yu

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=20170314173803.GA17126@amd \
    --to=pavel@ucw.cz \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=yu.c.chen@intel.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).