From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F49EC433F5 for ; Thu, 6 Oct 2022 16:15:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231594AbiJFQP2 (ORCPT ); Thu, 6 Oct 2022 12:15:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231458AbiJFQPY (ORCPT ); Thu, 6 Oct 2022 12:15:24 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A57665266 for ; Thu, 6 Oct 2022 09:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=V4NVYpP1YT+fA8f3Wmd6Cn01Iw4hE5hXGGRmCJ0X+Bk=; b=OYY60UvKbC6oHUX+5davBO+wOd RiRGW+8WreSj1Y3SD9pnbCvf7vLMrXK1IdkTSw7dMP+NpS0GS46NuojRV5PhIEXTL0IKxMveuH5Z0 F+ta/8hVH/yEDACEPFgDC3cp6KvK4gCWQR+KAUbdGK1n1lZDg4w6MNAHIWKLX9x1pMqcQ5gwiAJUA Z3qhScXnaZ54ByJgEIlh7bsvEQ7YYRaAyXHNgDT0rzf5aev7Rok7HZhHn4BuPUEpnZPm6Na0UgJzW FFXZBg9jt9EagrJS/qzdRPV0Oke8aYyowT4eBZtGCOUKOPyVzqGssH0fh/h2DmOSiozvTEovuue7r 7W+lio9g==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1ogTWW-001GZm-Cb; Thu, 06 Oct 2022 16:15:00 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7BF0A30017D; Thu, 6 Oct 2022 18:14:59 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 56D3E209DA438; Thu, 6 Oct 2022 18:14:59 +0200 (CEST) Date: Thu, 6 Oct 2022 18:14:59 +0200 From: Peter Zijlstra To: "Brown, Len" Cc: Ricardo Neri , Juri Lelli , Vincent Guittot , "Neri, Ricardo" , "Shankar, Ravi V" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Mel Gorman , "Wysocki, Rafael J" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Chen, Tim C" Subject: Re: [RFC PATCH 15/23] thermal: intel: hfi: Report per-cpu class-specific performance scores Message-ID: References: <20220909231205.14009-1-ricardo.neri-calderon@linux.intel.com> <20220909231205.14009-16-ricardo.neri-calderon@linux.intel.com> <20221005235959.GB29251@ranerica-svr.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 06, 2022 at 03:05:18PM +0000, Brown, Len wrote: > > > > 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. 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. > 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.