All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Guilhem Lettron <guilhem@barpilot.io>
Cc: Zhang Rui <rui.zhang@intel.com>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Len Brown <lenb@kernel.org>, Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] intel_idle: Add ICL support
Date: Wed, 26 Aug 2020 18:21:21 +0200	[thread overview]
Message-ID: <CAJZ5v0jkgVn88H9K0n0SX_xLPCgMYXXSVHXLLYaWvynGOMLf=g@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0j4FXH26rZCjM9Csd56skPVbRpM7iFcKYAFMmLFX54+bg@mail.gmail.com>

On Wed, Aug 26, 2020 at 6:02 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Aug 26, 2020 at 4:04 PM Guilhem Lettron <guilhem@barpilot.io> wrote:
> >
> > On Wed, 26 Aug 2020 at 15:41, Zhang Rui <rui.zhang@intel.com> wrote:
> > >
> > >
> > > This is really hard to read.
> > > can you please attach the two turbostat output as attachments?
> >
> > of course :)
>
> Thanks!
>
> A couple of things happen here AFAICS.
>
> First, your processor seems to be unable to enter package C-states
> below PC3, so probably there is a device (most likely a PCI one)
> preventing it from doing that in the system.  If all goes well, it
> should be able to get to at least PC8 without suspending the whole
> system.  That needs to be dealt with in the first place before we can
> draw meaningful conclusions regarding which set of C-states to expose
> and whether or not the one exposed via ACPI is sufficient.
>
> To that end, I would try to upgrade the graphics firmware and see if
> you can get some nonzero PC8 residency then.
>
> Second, ACPI exposes C1, C7s and C10 only and so you don't get any
> CPU-C6 residency without the patch, but instead you get more CPU-C7
> residency and more CPU-C1 residency.  It is hard to say which is
> better in principle, but if you look at what is asked for by the
> governor, it turns out that deep C-states (C8-C10) are requested
> around 54% of the time with the patch, whereas without it the ACPI_C3
> state (corresponding to C10) is requested approximately 24% of the
> time, which is much less often.  That appears to translate to the
> difference in PC2 residency (~30% with the patch vs ~17% without it).
>
> Note, however, that (with the patch) C10 itself is asked for around
> 11% of the time which in turn is much less than the ~24% for the
> corresponding ACPI_C3 (without the patch).
>
> Overall, it looks like exposing C8 is beneficial from the energy usage
> perspective, because (in the future, when the "blocking" device is
> taken care of and the system can enter PC8 and deeper package
> C-states) it may allow PC8 to be entered more often in principle, even
> though it may reduce the amount of time spent in PC10 too (PC10 may be
> generally difficult to enter, though).  [Here I'm assuming that the
> processor enters PC3 or PC2 instead of PC8 or deeper which cannot be
> entered due to some resource dependency.]
>
> OTOH exposing C1E doesn't seem to make much of a difference and
> exposing C6 only causes it to be asked for instead of C7s, so exposing
> the latter alone should be sufficient in theory.

I need to correct myself here.

With the patch C7s is exposed with the target residency of C8 which is
why it is almost never selected by the governor and that's why C6 is
kind of "instead" of it.

So it looks like it might be beneficial to expose C8 (instead of C7s)
and C6 with the target residency significantly less than that of C8.

> So IMO the set of C-states exposed by ACPI looks almost enough, but
> the jury is out until you can make the system be able to enter at
> least PC8.

  reply	other threads:[~2020-08-26 16:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26 12:04 [PATCH] intel_idle: Add ICL support Guilhem Lettron
2020-08-26 12:43 ` Rafael J. Wysocki
2020-08-26 13:03   ` Guilhem Lettron
2020-08-26 13:09     ` Artem Bityutskiy
2020-08-26 13:19       ` Guilhem Lettron
2020-08-26 13:20       ` Rafael J. Wysocki
2020-08-26 13:16     ` Artem Bityutskiy
2020-08-26 13:18       ` Artem Bityutskiy
2020-08-26 13:21         ` Rafael J. Wysocki
2020-08-26 13:32         ` Guilhem Lettron
2020-08-26 13:41           ` Zhang Rui
2020-08-26 14:04             ` Guilhem Lettron
2020-08-26 16:02               ` Rafael J. Wysocki
2020-08-26 16:21                 ` Rafael J. Wysocki [this message]
2020-08-26 16:39                 ` Artem Bityutskiy
2020-08-26 16:43                   ` Rafael J. Wysocki
2020-08-26 16:46                     ` Guilhem Lettron
2020-08-26 17:00                       ` Rafael J. Wysocki
2020-08-26 17:47                         ` Zhang Rui
2020-08-26 16:52                     ` Artem Bityutskiy
2020-08-26 16:19               ` Artem Bityutskiy
2020-08-26 16:25                 ` Artem Bityutskiy
2020-08-26 16:28                   ` Artem Bityutskiy
2020-08-26 16:41                 ` Rafael J. Wysocki
     [not found]   ` <CAGX5Wg0655U71nFcaAJXmj1XMA3MjnCVn=q1Pf=7LLyryHhroQ@mail.gmail.com>
2020-08-26 13:17     ` Rafael J. Wysocki
2020-08-26 13:34       ` Guilhem Lettron

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='CAJZ5v0jkgVn88H9K0n0SX_xLPCgMYXXSVHXLLYaWvynGOMLf=g@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=dedekind1@gmail.com \
    --cc=guilhem@barpilot.io \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@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 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.