Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220909231205.14009-1-ricardo.neri-calderon@linux.intel.com>
 <20220909231205.14009-16-ricardo.neri-calderon@linux.intel.com>
 <YzLlk8NL5qkOOxzX@hirez.programming.kicks-ass.net> <20221005235959.GB29251@ranerica-svr.sc.intel.com>
 <Yz6XQHafjIpfkyyY@hirez.programming.kicks-ass.net> <Yz6cjzrmu8HNPhhy@hirez.programming.kicks-ass.net>
 <MN0PR11MB601075B47DC7626876CC91DAE05C9@MN0PR11MB6010.namprd11.prod.outlook.com>
 <Yz7/A62YxHfmgYog@hirez.programming.kicks-ass.net>
In-Reply-To: <Yz7/A62YxHfmgYog@hirez.programming.kicks-ass.net>
From:   Len Brown <lenb@kernel.org>
Date:   Fri, 7 Oct 2022 13:20:48 +0200
Message-ID: <CAJvTdKn8qQwTw-BY_Rp=DOi+3is5tQqoJoNWDAH7ub8XTsimbw@mail.gmail.com>
Subject: Re: [RFC PATCH 15/23] thermal: intel: hfi: Report per-cpu
 class-specific performance scores
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     "Brown, Len" <len.brown@intel.com>,
        Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        "Neri, Ricardo" <ricardo.neri@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        Ben Segall <bsegall@google.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Mel Gorman <mgorman@suse.de>,
        "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Valentin Schneider <vschneid@redhat.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Chen, Tim C" <tim.c.chen@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Oct 6, 2022 at 6:15 PM Peter Zijlstra <peterz@infradead.org> wrote:

> > 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.
>
> I have a NUC, so laptop part with limited thermals (the Lenovo P360
> Ultra was announed just after I ordered the P360 Tiny). Still I wasn't
> able to trigger this during normal operation.

To force an update, scribble on the software power limit:

# echo 0 >   /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
# echo 0 >   /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw

Note that your P-unit may not instantaneously respond to this stimulus.

> > 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.
>
> Make *very* sure those upcoming chips don't broadcast that interrupt.
> Broadcast interrupts are unconditional crap.
>
> Broadcast interrupts every 10ms is terrifying crap and a good reason for
> people to force disable this stuff.

The package-wide broadcast interrupt is indeed, ugly, and we've
been screaming bloody murder about it from day 1.  Unfortunately
the chip pipeline is long and deep, and so more chips with this issue will
materialize before the broadcast interrupt issue completely goes away.
--
Len Brown, Intel