Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5446951pxj; Wed, 26 May 2021 10:41:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC6cQTmJQ3OXYUXQTjlvsbKosuhUDthsT+RWK4auZzvazBZG1WMLu7gq31IzZLWqK+ISzI X-Received: by 2002:a05:6e02:2141:: with SMTP id d1mr19396160ilv.190.1622050872143; Wed, 26 May 2021 10:41:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622050872; cv=none; d=google.com; s=arc-20160816; b=TdSYS+AjL4rQC08yVhsd4qSlI3DusV8T8S03dpI8EW+fzzMae9DHeGSCs7H/AVqoPO wLOcYxnRPj8NEnp/M/PBNhHiNGyIcqxNPs/XkJ1cFahItZMkDpBUIl8e3cwxEuYXLtYR 6UFOeUSP4syrNDeIZX5X8XuYzE23yNM46wKA61RsJswZyqDl9TaoiZ2L+lYQYTJId8nh n1TBwfo2XrC28SXVozbnn3ISEA6lgRensdlzkAztUOR2fcm3g4azNtpQvu1eDsO0KSX/ F6B+QTrf2SzkE49TggYVt1S9UdkTinLsOK5SEeK64kuhYuVQhSY/3WA1/aAr8b61n1Ay BH6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=osLKpw4UHi+S3wDyzSUBKuGdHlsaCvn/H7RINAfknUI=; b=SSzOOT09zpqBw8d1S9fv/gh0cExrHrp/saL9J+AIEb9Ksk/Cf2pw0Iul7jjFUzVdnr Sa66CURPNxouVPX906xGCvwC6x/moaA1zHE4UTqJ9rFYag9osYcaqYptdCwG+IJGKrFM sW4NBRPVe5CsbUZAxdjWZSjB2ptQqxhKLMdNVFwdsJ8aD9IqepIHGoQZSVA4bYI5qumJ UhgG2McMTZgZYoTZnke7Ema4a3NIN//RqYcYtf3B/WP9Wb8T2oVr6RlGh+0qTc4mUJG+ cRn4NGPh3MKENbilq8CtFN2ffO+QenUD4AhDrXxnTH7UNYjjrCuUxKISg71obfWV+hr2 /teQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h19si15882256iow.36.2021.05.26.10.40.57; Wed, 26 May 2021 10:41:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234515AbhEZLyX (ORCPT + 99 others); Wed, 26 May 2021 07:54:23 -0400 Received: from foss.arm.com ([217.140.110.172]:43426 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234573AbhEZLwV (ORCPT ); Wed, 26 May 2021 07:52:21 -0400 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 5D54C1516; Wed, 26 May 2021 04:50:49 -0700 (PDT) Received: from [10.57.31.7] (unknown [10.57.31.7]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 675A13F73B; Wed, 26 May 2021 04:50:47 -0700 (PDT) Subject: Re: [PATCH v2 0/3] EM / PM: Inefficient OPPs From: Lukasz Luba To: Viresh Kumar Cc: Vincent Donnefort , peterz@infradead.org, rjw@rjwysocki.net, vincent.guittot@linaro.org, qperret@google.com, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com, dietmar.eggemann@arm.com References: <1621616064-340235-1-git-send-email-vincent.donnefort@arm.com> <20210526034751.5fl4kekq73gqy2wq@vireshk-i7> <20210526090141.GA408481@e120877-lin.cambridge.arm.com> <20210526093807.sih5y4lgltsz3r74@vireshk-i7> <17d88121-4809-dc31-1b57-2134ec868c8b@arm.com> Message-ID: <4a3db514-bec5-394f-ec3f-15c23b44b8f6@arm.com> Date: Wed, 26 May 2021 12:50:45 +0100 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: 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-kernel@vger.kernel.org On 5/26/21 11:39 AM, Lukasz Luba wrote: > [snip] To summarize: - we don't want to disable some OPPs - we want to give a 'hint' from energy perspective - we rely on SchedUtil 2nd stage which clamps this freq hint value to allowed OPPs which might set actually not the one what we see as 'efficient' -- we don't harm some existing platform which might needs these 'inefficient' OPPs in some use cases - we pay some extra cost in this SchedUtil freq switch path, which shouldn't harm too much. -- we pay this cost only for arm/arm64 platforms which use EM -- this cost is balanced by the benefit that we see in benchmarks and measured energy -- the LUT might limit the impact I hope this would help to better understand the scope and impact of this patch set. Regards, Lukasz