lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 6 Oct 2022 15:05:18 +0000
From:   "Brown, Len" <len.brown@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
CC:     Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        "Neri, Ricardo" <ricardo.neri@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Ben Segall <bsegall@...gle.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Mel Gorman <mgorman@...e.de>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Valentin Schneider <vschneid@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Chen, Tim C" <tim.c.chen@...el.com>
Subject: RE: [RFC PATCH 15/23] thermal: intel: hfi: Report per-cpu
 class-specific performance scores

> > > Does any of that data actually ever change? Isn't the class score 
> > > fixed per CPU type?

Depends on the chip.

As we described at LPC, the ADL chips shipping today update their tables in response
to RAPL working to keep the system below PL1.  Linux or user-space can scribble on PL1
at any time, so technically, this table update can happen at any time.

That said, it is true that, say, an ADL desktop part that operates with plenty of power and cooling
will send the initial table and never have a need to update the table after that.

Upcoming chips are smarter and will give us more dynamic information.
We expect the P-unit to send only "meaningful" changes, and that they
Shall not occur more often than every 10ms.

Re: class core fixed per CPU type
Usually (but not always) the class score for every CPU of a type will be the same,
They can change, but likely will all change in concert.
However the scores for the different types can change relative to each other.

The not-always bit is because CPUs of the same type may not actually be identical.
Recall that ITMT was originally implemented to favor some Pcores that are
Faster than other Pcores of the same type.  Similarly, I would expect that
Ecores within a module will be uniform, but some Ecore modules may
differ from modules -- and how they differ can change at run-time.

Cheers,
-Len



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ