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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA45BC433FE for ; Tue, 9 Nov 2021 17:51:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 93BC9611BF for ; Tue, 9 Nov 2021 17:51:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241413AbhKIRxz (ORCPT ); Tue, 9 Nov 2021 12:53:55 -0500 Received: from foss.arm.com ([217.140.110.172]:36814 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239360AbhKIRxy (ORCPT ); Tue, 9 Nov 2021 12:53:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5201EED1; Tue, 9 Nov 2021 09:51:08 -0800 (PST) Received: from [10.57.26.224] (unknown [10.57.26.224]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 015893F7F5; Tue, 9 Nov 2021 09:51:04 -0800 (PST) Subject: Re: [PATCH 6/7] thermal: netlink: Add a new event to notify CPU capabilities change To: Srinivas Pandruvada Cc: Ricardo Neri , "Rafael J. Wysocki" , Daniel Lezcano , linux-pm@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, Len Brown , Aubrey Li , Amit Kucheria , Andi Kleen , Tim Chen , "Ravi V. Shankar" , Ricardo Neri , linux-kernel@vger.kernel.org References: <20211106013312.26698-1-ricardo.neri-calderon@linux.intel.com> <20211106013312.26698-7-ricardo.neri-calderon@linux.intel.com> <2160a0b8-59ec-03a1-1fd5-a3f98085be07@arm.com> <5e4d7661-1e91-0c72-ae02-b2c60c2ad95e@arm.com> <94ddfd1177c3f119de2794d9fb659a6578f560c6.camel@linux.intel.com> From: Lukasz Luba Message-ID: Date: Tue, 9 Nov 2021 17:51:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <94ddfd1177c3f119de2794d9fb659a6578f560c6.camel@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 11/9/21 2:15 PM, Srinivas Pandruvada wrote: > On Tue, 2021-11-09 at 13:53 +0000, Lukasz Luba wrote: >> Hi Srinivas, >> >> On 11/9/21 1:23 PM, Srinivas Pandruvada wrote: >>> Hi Lukasz, >>> >>> On Tue, 2021-11-09 at 12:39 +0000, Lukasz Luba wrote: >>>> Hi Ricardo, >>>> >>>> >>>> On 11/6/21 1:33 AM, Ricardo Neri wrote: >>>>> From: Srinivas Pandruvada >>>>> >>>>> Add a new netlink event to notify change in CPU capabilities in >>>>> terms of >>>>> performance and efficiency. >>>> >>>> Is this going to be handled by some 'generic' tools? If yes, >>>> maybe >>>> the values for 'performance' might be aligned with capacity >>>> [0,1024] ? Or are they completely not related so the mapping is >>>> simply impossible? >>>> >>> >>> That would have been very useful. >>> >>> The problem is that we may not know the maximum performance as >>> system >>> may be booting with few CPUs (using maxcpus kernel command line) >>> and >>> then user hot adding them. So we may need to rescale when we get a >>> new >>> maximum performance CPU and send to user space. >>> >>> We can't just use max from HFI table at in instance as it is not >>> necessary that HFI table contains data for all CPUs. >>> >>> If HFI max performance value of 255 is a scaled value to max >>> performance CPU value in the system, then this conversion would >>> have >>> been easy. But that is not. >> >> I see. I was asking because I'm working on similar interface and >> just wanted to understand your approach better. In my case we >> would probably simply use 'capacity' scale, or more >> precisely available capacity after subtracting 'thermal pressure' >> value. >> That might confuse a generic tool which listens to these socket >> messages, though. So probably I would have to add a new >> THERMAL_GENL_ATTR_CPU_CAPABILITY_* id >> to handle this different normalized across CPUs scale. > I can add a field capacity_scale. In HFI case it will always be 255. In > your cases it will 1024. > > Sounds good, with that upper limit those tools would not build up assumptions (they would have to parse that scale value). Although, I would prefer to call it 'performance_scale' if you don't mind. I've done similar renaming s/capacity/performance/ in the Energy Model (EM) some time ago [1]. Some reasons: - in the scheduler we have 'Performance Domains (PDs)' - for GPUs we talk about 'performance', because 'capacity' sounds odd in that case [1] https://lore.kernel.org/linux-pm/20200527095854.21714-2-lukasz.luba@arm.com/