Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4790008pxj; Tue, 22 Jun 2021 08:06:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsi5li4sSUA7nbSOPBiJyKOusBBAEg1Ne4fTIM2pSU1zrmKEPjQhRpPzUWshw/xMGEdgyw X-Received: by 2002:a17:907:a8f:: with SMTP id by15mr4474019ejc.91.1624374384552; Tue, 22 Jun 2021 08:06:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624374384; cv=none; d=google.com; s=arc-20160816; b=YzVE0NGlOyAPx+fTBqTkKsQ3/gjettczBe2yxl0CV8noxiSTtQ2oX/nmgLDaYf3Z2e heXgHgr02agu0Gxct4xr5t08L47YV+Ac3xqZhBlszZ1ypPkGOV0TZeCf4HZb/HSwcHII prJxIU/xH3Gu/zpXn7+nn87fLshMbph79IbL/PnJaONnT2Nq3wDC5gboDXNl2qpJ917e DNpcxefiKWJfD9CkVXoCZV8Fum+6eBj5yDjgza4mgspTqttfnhcn7xR9D39n5UCJ34LA iYXj5Fcw4En23XkDlLfqyNN28R9GPHuJ3PjfnJSRnoNzy23LwaVFo5M9zvZSopvEBsI0 G3FA== 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:from:references :cc:to:subject; bh=uuce4OrN9eFKfLLayhFbhTDAcNYmB7SncxT+6vT8yTo=; b=e8qFVoDANIttj9Wbz78fcWaOYahT9z4+iIjy6niQiKjyxTxNj7+2WtyjigeGLnJ6KL PPCgJEMiMJ6fi9fRyFiJfNBYqmneUdUhD7DdqPtOK8wrZR+0+UL2p/abd34LPWK754MA Wh0k3jhUCzn9eLKXeguleZhjwhZ8s2SjKbE1QJObbe9HItdigLQGXaERAFAGEoaS/kRt GhudDJ+6r5iHpZ1w/Y8J1UNlWgmMxm/Fe0dPKObJIEULId/k73KOCr08J0xknvrHbA0b BgATP8zQDWUI6Mcr0iENWQoMLifSnIMowJQBWr07q++eH24XJlzIT3kAgzq6gnUNxGK1 8nsQ== 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 i11si24314647edb.418.2021.06.22.08.05.59; Tue, 22 Jun 2021 08:06:24 -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 S231613AbhFVPEW (ORCPT + 99 others); Tue, 22 Jun 2021 11:04:22 -0400 Received: from foss.arm.com ([217.140.110.172]:50706 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230047AbhFVPEU (ORCPT ); Tue, 22 Jun 2021 11:04:20 -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 12681ED1; Tue, 22 Jun 2021 08:02:04 -0700 (PDT) Received: from [10.57.7.129] (unknown [10.57.7.129]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F29AE3F718; Tue, 22 Jun 2021 08:02:01 -0700 (PDT) Subject: Re: [RFC PATCH 2/4] cpuidle: Add Active Stats calls tracking idle entry/exit To: "Rafael J. Wysocki" Cc: Linux Kernel Mailing List , Daniel Lezcano , Linux PM , Amit Kucheria , "Zhang, Rui" , Dietmar Eggemann , Chris Redpath , Beata.Michalska@arm.com, Viresh Kumar , "Rafael J. Wysocki" , Amit Kachhap References: <20210622075925.16189-1-lukasz.luba@arm.com> <20210622075925.16189-3-lukasz.luba@arm.com> <2f7d855c-5232-ddbe-8403-db3596dcebc5@arm.com> From: Lukasz Luba Message-ID: <02015810-af5e-68d1-c83f-d458025556ee@arm.com> Date: Tue, 22 Jun 2021 16:02:00 +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 6/22/21 3:44 PM, Rafael J. Wysocki wrote: > On Tue, Jun 22, 2021 at 3:59 PM Lukasz Luba wrote: >> >> >> >> On 6/22/21 1:33 PM, Rafael J. Wysocki wrote: >>> On Tue, Jun 22, 2021 at 9:59 AM Lukasz Luba wrote: >>>> >>>> The Active Stats framework tracks and accounts the activity of the CPU >>>> for each performance level. It accounts the real residency, >>> >>> No, it doesn't. It just measures the time between the entry and exit >>> and that's not the real residency (because it doesn't take the exit >>> latency into account, for example). >> >> It's 'just' a 'model' and as other models has limitations, but it's >> better than existing one, which IPA has to use: >> cpu_util + currect_freq_at_sampling_time > > But the idle duration is already measured by cpuidle as > last_residency_ns. Why does it need to be measured once more in > addition to that? So the last_residency_ns calculation is done when the CPU is exiting idle. I need something more, consider this scenario: IPA wakes up every 100ms and estimates power used in past 100ms. If one CPU entered idle and is still there for 30ms, then my Active Stats will tell me this. The last_residency_ns mechanism won't, since it available when CPU is woken up (I don't want to wake up CPUs). > >>> >>>> when the CPU was not idle, at a given performance level. This patch adds needed calls >>>> which provide the CPU idle entry/exit events to the Active Stats >>>> framework. >>> >>> And it adds overhead to overhead-sensitive code. >>> >>> AFAICS, some users of that code will not really get the benefit, so >>> adding the overhead to it is questionable. >>> >>> First, why is the existing instrumentation in the idle loop insufficient? >> >> The instrumentation (tracing) cannot be used at run time AFAIK. I need >> this idle + freq information combined in a running platform, not for >> post-processing (like we have in LISA). The thermal governor IPA would >> use them for used power estimation. > > What about snapshotting last_residency_ns in the CPU wakeup path? That would be available in the exit path, for running CPUs only. > >>> >>> Second, why do you need to add locking to this code? >> >> The idle entry/exit updates the CPU's accounting data structure. >> There is a reader of those data structures: thermal governor, >> run from different CPU, which is the reason why I put locking for them. > > So please consider doing it in a lockless manner and avoid running > this code when it is not needed in the first place. > I'll have a look at this option.