The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	platform-driver-x86@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86/intel-uncore-freq: Do not present separate package-die domain
Date: Tue, 13 Aug 2024 06:58:32 -0700	[thread overview]
Message-ID: <826971a048e27f726e8258d4355bdc976a74d0f4.camel@linux.intel.com> (raw)
In-Reply-To: <3982985e-d8c1-7307-7187-aae438d9b75e@linux.intel.com>

On Tue, 2024-08-13 at 10:51 +0300, Ilpo Järvinen wrote:
> On Mon, 12 Aug 2024, srinivas pandruvada wrote:
> > On Mon, 2024-08-12 at 14:16 +0300, Ilpo Järvinen wrote:
> > > On Wed, 31 Jul 2024, Srinivas Pandruvada wrote:
> > > 
> > > > The scope of uncore control is per power domain in a package
> > > > and
> > > > die.
> > > > A package-die can have multiple power domains on some
> > > > processors.
> > > > In this
> > > > case package-die domain (root domain) aggregates all
> > > > information
> > > > from
> > > > power domains in it.
> > > > 
> > > > On some processors, CPUID enumerates the die number same as
> > > > power
> > > > domain
> > > > ID. In this case there is one to one relationship between
> > > > package-
> > > > die and
> > > > power domain ID. There is no use of aggregating information
> > > > from
> > > > all
> > > > power domain IDs as the information will be duplicate and
> > > > confusing. In
> > > > this case do not create separate package-die domain.
> > > 
> > > Hi Srinivas,
> > > 
> > > I got confused by this changelog because its order is quite
> > > illogical.
> > > 
> > > First paragraph talks about case A. When you say "all
> > > information" 
> > > is "aggregated", I immediately make the assumption that the
> > > aggregated 
> > > information is what is wanted because, well, you normally want
> > > "all 
> > > information" and nothing else is being told here.
> > > 
> > > Second paragraph starts to talk about case B and then suddenly
> > > switches to 
> > > talk what should have been done in case A (that aggregated
> > > information is 
> > > useless/confusing).
> > > 
> > Is this any better:
> > 
> > "
> > The scope of uncore control is per power domain in a package and
> > die
> > with TPMI.
> > 
> > There are two types of processor configurations possible:
> > 1. A compute die is not enumerated in CPUID. In this case there is
> > only
> > one die in a package. In this case there will be multiple power
> > domains
> > in a single die.
> > 2. A power domain in a package is enumerated as a compute die in
> > CPUID.
> > So there is one to one relationship between a die and power domain.
> 
> So there are multiple dies in a package and one to one relationship 
> between a die and power domain.
In case 2, yes.

> 
> > 
> > To allow die level controls, the current implementation creates a
> > root
> > domain and aggregates all information from power domains in it.
> > This
> > is well suited for configuration 1 above.
> > 
> > But when newer processors use configuration 2 above, this will
> > present
> > redundant information, So no use of aggregating. In this case do
> > not
> > create separate root domain.
> > "
> 
> Yes, it is now clearer. A minor suggestion above to better map with
> the 
> code (explicitly stating the condition that matches to the check done
> by the code).
OK.

Thanks,
Srinivas

> 


      reply	other threads:[~2024-08-13 13:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 18:57 [PATCH] platform/x86/intel-uncore-freq: Do not present separate package-die domain Srinivas Pandruvada
2024-08-12 11:16 ` Ilpo Järvinen
2024-08-12 17:09   ` srinivas pandruvada
2024-08-13  7:51     ` Ilpo Järvinen
2024-08-13 13:58       ` srinivas pandruvada [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=826971a048e27f726e8258d4355bdc976a74d0f4.camel@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /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