From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6451E17C79 for ; Mon, 29 Apr 2024 09:25:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714382720; cv=none; b=pr7cLJDHuolGndT1r6q4N24l/+FQSAEaUJ7f60Lhoqo7M5fDYPiN1nNfpICLCOC+vGr7NkJVMUO3ZvkWCLSLIOny7MRCS+AyeyZbsfqe4FR4Za4f/P1Chm5y+F07XK0d/ICuEVesmrpQlbdK2cMW3A9gAVEstXulkKYpHeiyOSI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714382720; c=relaxed/simple; bh=K8qRHDrtqHgZqOAB3DxYwHDgSoSpq4jFqaSKLYGlW48=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b1Fb5hUeo9ix2fldKnCfZQxsR22Asw5XveeytHDvTecm2DZLc7CW3JlIOXc90ClxEeI1sCtTFcv9DyeyshvBahsy5gU+kfa+WwbGOkNpFBEBIP5uxMymsoUXCqGliqC3ZS7n4x815VKts1IqGcYgcLsDRJYcnWOUlY/XanE9j1Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=IvaStaba; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IvaStaba" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2a4b457769eso3476283a91.2 for ; Mon, 29 Apr 2024 02:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1714382718; x=1714987518; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CP7urYo+70JxTDdjocGamt4MhJNpCFDJ7gBO0gt6mpU=; b=IvaStabafOk9r/3/+1SK0zcO+Os8fmMR0GTm6VshCuT18Ekfzb5TA/XePxgqKrDJiX 0GlljWcPI1ql1/I+sUZ1jJG+ixBl8zZ8dmTRYy8oFE50hmbABywTi7ChPFlPYF7wupcb rrL8XSPsSDgmAlzKcZE77EdxHASiX5RQJ6YhOQdciJAi3DpmG+F9nJAv12OT/129t/IM KvXt6P5tFRI7GGZnyA0zeh2IuH5Fhy9abA7atHs8S7HmGnKudn+twq5u+5G8vOQX9p/F bsbOHj3GCZnGwL+GzQncW9vII6EAVinkA9FvrxQvir5fcIjsJDVYTJq+MmThC/2UDx+h dbwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714382718; x=1714987518; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CP7urYo+70JxTDdjocGamt4MhJNpCFDJ7gBO0gt6mpU=; b=cU9mjsLEP/4ioMifViibyhTRcIq1dvOqUy+ox6fMzQDnJbD/ZTMv2/bBxK3sbt+ZGJ 9VxIgH/QTp/aD9b7NWutzfKG79tI3ZXkgL72THnbNJN2G+lWsoiI7BgHJa44JwI9PCO/ hhKy/NxZEG6ios/4VmIf6NJK8hgzkqJyTX94V+pGCDXEUcdsSEoR6ozJKJyKyfhoaU87 s6YX6jmss+qU04+wvhsPAOMi3y5fRiYwBpFPrkiFIwbr06S+omm4nz4t5aa265QCVbvW 93V6tEOpAeTk9cGA0z8+1NBzuxP2kBZrC+l4c8VQAfoSfwaar4R263JaCiDsv9duq/W/ BIhQ== X-Forwarded-Encrypted: i=1; AJvYcCUWBV5Xaj7EXk/399kvz9itzIx6Nvc18hgZmw++16DHbAf40mpeUkK9IuQbvHtji1A3JRcz0Viv2QW7ss+5dl2U2c5R3/RXnSwRXulH X-Gm-Message-State: AOJu0YwZvOjFSe9kiVlOycwxR1eTk0iPoDB6UiqJiXLVq/jC7qlpRb3Y 53LpydezN9Hb6PIgd6ItWFKPZJkNVLU/iKnbQPhgtrpRzzqveshHh98w6TLiCrBiF47HBeO5YV1 m X-Google-Smtp-Source: AGHT+IFITCOMk0yA7pLp8TcRe78mmJzy+qa5QjSau8VCgla5VWdIzElzIG0vSpMAMhKUMzDvhbSVrA== X-Received: by 2002:a17:90b:3d4:b0:2a6:1625:368c with SMTP id go20-20020a17090b03d400b002a61625368cmr8711509pjb.6.1714382718462; Mon, 29 Apr 2024 02:25:18 -0700 (PDT) Received: from localhost ([122.172.87.52]) by smtp.gmail.com with ESMTPSA id gb23-20020a17090b061700b002b15a672805sm2339899pjb.23.2024.04.29.02.25.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 02:25:17 -0700 (PDT) Date: Mon, 29 Apr 2024 14:55:15 +0530 From: Viresh Kumar To: Beata Michalska Cc: Vanshidhar Konda , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, vincent.guittot@linaro.org, sumitg@nvidia.com, yang@os.amperecomputing.com, lihuisong@huawei.com Subject: Re: [PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq Message-ID: <20240429092515.2ehk4ifcul6mbaxh@vireshk-i7> References: <20240405133319.859813-1-beata.michalska@arm.com> <20240405133319.859813-5-beata.michalska@arm.com> <76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On 26-04-24, 12:45, Beata Michalska wrote: > It seems that we might need to revisit the discussion we've had around > scaling_cur_freq and cpuinfo_cur_freq and the use of arch_freq_get_on_cpu. > As Vanshi has raised, having both utilizing arch specific feedback for > getting current frequency is bit problematic and might be confusing at best. > As arch_freq_get_on_cpu is already used by show_scaling_cur_freq there are not > many options we are left with, if we want to kee all archs aligned: > we can either try to rework show_scaling_cur_freq and it's use of > arch_freq_get_on_cpu, and move it to cpuinfo_cur_freq, which would align with > relevant docs, though that will not work for x86, or we keep it only there and > skip updating cpuinfo_cur_freq, going against the guidelines. Other options, > purely theoretical, would involve making arch_freq_get_on_cpu aware of type of > the info requested (hw vs sw) or adding yet another arch-specific implementation, > and those are not really appealing alternatives to say at least. > What's your opinion on this one ? Hi Beata / Vanshidhar, Lets forget for once what X86 and ARM may have done and think about it once again. I also had a chat with Vincent today about this. The documentation says it clearly, cpuinfo_cur_freq is the one received from hardware and scaling_cur_freq is the one requested from software. Now, I know that X86 has made both of them quite similar and I suggested to make them all aligned (and never received a reply on my previous message). There are few reasons why it may be worth keeping the definition (and behavior) of the sysfs files as is, at least for ARM: - First is that the documentation says so. - There is no point providing the same information via both the interfaces, there are two interfaces here for a reason. - There maybe tools around which depend on the documented behavior. - From userspace, currently there is only one way to know the exact frequency that the cpufreq governors have requested from a platform, i.e. the value from scaling_cur_freq. If we make it similar to cpuinfo_cur_freq, then userspace will never know about the requested frequency and the eventual one and if they are same or different. Lets keep the behavior as is and update only cpuinfo_cur_freq with arch_freq_get_on_cpu(). Makes sense ? -- viresh 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 686A8C4345F for ; Mon, 29 Apr 2024 09:25:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=My+Y+0CzBoJb1TlB9tPB+YZq32UT7GEgtOXy/9aiwyM=; b=Yy628n6hBwL88c UmU+DJJ7cktRVr8R+7HgHomqx8/aDnCDTy4hpbyZC3pfxFwPXGlnrWIu6aKXa75kCbI5AJoPurKif vPnH/PJ/s41k+N1P3F1jjv7mHPvEGrut9jWhraYI8/cks7AAlB+HnVhSLvLQDhXh5ho6AoQiO9FFl LVnURSwyaLYXU4PsdP/IO8HRXtn478n4LOm0IlyuQG3vLk0kMhkk1ir/bkZ5NRHMjeotR+P+m5iEb ht7naQPyOUNcsRujJXn/A+roKu6d4NEfUanbwWy20nyq8lMociTsk9F9tevL+kQDTDowfRXs6r3DI dwlF0JNcDp1vpnX8VD9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1NGF-000000026fj-0BEu; Mon, 29 Apr 2024 09:25:23 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1NGC-000000026ed-1Trw for linux-arm-kernel@lists.infradead.org; Mon, 29 Apr 2024 09:25:21 +0000 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2a4b457769eso3476284a91.2 for ; Mon, 29 Apr 2024 02:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1714382718; x=1714987518; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CP7urYo+70JxTDdjocGamt4MhJNpCFDJ7gBO0gt6mpU=; b=NEekebmMKVDkDB6ZcaZUUo3G2OlWhddoEPXMdbkBCcQIzbY/iGOQ75arv4X+1S+8iE KjCoRiymXh2fRh6WX7zYcIMGpHd0sKgg20fVATxckAOQB3u7UCdFLzGFxM7vJApkXVMb Ox912DNMPmeYC6kd+4Z1RK37aJT3bXh8WYHUz521BkVm+XxfajOWY/nZq+qfsNzD4Gxk qOBX89uPMM7p/us4yFxfHseqUIkdGBL79BiyBx+9AVArKtfmHNx53rLftyEU/BZSs7nT gAU3vh0g5tc0TstD8dVHrErPaX66AKkVnok5Rl2kYKYBK9i3fWzHN7AbylzHUUj08c+4 pDIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714382718; x=1714987518; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CP7urYo+70JxTDdjocGamt4MhJNpCFDJ7gBO0gt6mpU=; b=G88yh/XyKCkfOQgXxW2UTSX558ZZccw40eUcNq+/WmPlz2pnqJvNQoLZF18t8NcOBc ROKdVCiK/fQ5oco2HUs69qz26ZiXLdAsYzhwauJOo/M3UJUKOX5jq3HF1nv+63fsDQ6w 0E/ZDJvp3PNN9HDXr4rW93C6gzEMiVhFVGpWWAAgzR4RAEXmnQvVL+MNiy6J0SfpRxqp r2pvTBgj+J4wcrwflod9+BgHrrGkXUgUXUhFTI2qSUZkgQ4rxN32OSXy8bMXcSz+UB2a ILZ9i6ZWXOrwKK8sI85kt57795yKmlK4gZNxFhhAXGQISwjdpaViRvIIa/uYC+aBtTRB j9qw== X-Forwarded-Encrypted: i=1; AJvYcCWEtqGkRwuSSLedSNK294rHsMw88s1bWgV+mpKfqmCeVdEHpm/ylPviMbmBA8Tc7QgBRARHxyxeCzg0gppkdBSXgRQ72/wbSyp7uquvtaJYPNzW+JM= X-Gm-Message-State: AOJu0YzKidSeRSlBgpIQAWTwpDOWVYMF43iR36YSwg1yKE3/3+b9lZTr qnlYMFIz2C4eW0nvFEVAv9Gs2ds8IMc4bFOCeWLt2NKG9LP/TtE8vaE0jSn00so= X-Google-Smtp-Source: AGHT+IFITCOMk0yA7pLp8TcRe78mmJzy+qa5QjSau8VCgla5VWdIzElzIG0vSpMAMhKUMzDvhbSVrA== X-Received: by 2002:a17:90b:3d4:b0:2a6:1625:368c with SMTP id go20-20020a17090b03d400b002a61625368cmr8711509pjb.6.1714382718462; Mon, 29 Apr 2024 02:25:18 -0700 (PDT) Received: from localhost ([122.172.87.52]) by smtp.gmail.com with ESMTPSA id gb23-20020a17090b061700b002b15a672805sm2339899pjb.23.2024.04.29.02.25.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 02:25:17 -0700 (PDT) Date: Mon, 29 Apr 2024 14:55:15 +0530 From: Viresh Kumar To: Beata Michalska Cc: Vanshidhar Konda , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, vincent.guittot@linaro.org, sumitg@nvidia.com, yang@os.amperecomputing.com, lihuisong@huawei.com Subject: Re: [PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq Message-ID: <20240429092515.2ehk4ifcul6mbaxh@vireshk-i7> References: <20240405133319.859813-1-beata.michalska@arm.com> <20240405133319.859813-5-beata.michalska@arm.com> <76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240429_022520_550081_68E3F55D X-CRM114-Status: GOOD ( 21.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26-04-24, 12:45, Beata Michalska wrote: > It seems that we might need to revisit the discussion we've had around > scaling_cur_freq and cpuinfo_cur_freq and the use of arch_freq_get_on_cpu. > As Vanshi has raised, having both utilizing arch specific feedback for > getting current frequency is bit problematic and might be confusing at best. > As arch_freq_get_on_cpu is already used by show_scaling_cur_freq there are not > many options we are left with, if we want to kee all archs aligned: > we can either try to rework show_scaling_cur_freq and it's use of > arch_freq_get_on_cpu, and move it to cpuinfo_cur_freq, which would align with > relevant docs, though that will not work for x86, or we keep it only there and > skip updating cpuinfo_cur_freq, going against the guidelines. Other options, > purely theoretical, would involve making arch_freq_get_on_cpu aware of type of > the info requested (hw vs sw) or adding yet another arch-specific implementation, > and those are not really appealing alternatives to say at least. > What's your opinion on this one ? Hi Beata / Vanshidhar, Lets forget for once what X86 and ARM may have done and think about it once again. I also had a chat with Vincent today about this. The documentation says it clearly, cpuinfo_cur_freq is the one received from hardware and scaling_cur_freq is the one requested from software. Now, I know that X86 has made both of them quite similar and I suggested to make them all aligned (and never received a reply on my previous message). There are few reasons why it may be worth keeping the definition (and behavior) of the sysfs files as is, at least for ARM: - First is that the documentation says so. - There is no point providing the same information via both the interfaces, there are two interfaces here for a reason. - There maybe tools around which depend on the documented behavior. - From userspace, currently there is only one way to know the exact frequency that the cpufreq governors have requested from a platform, i.e. the value from scaling_cur_freq. If we make it similar to cpuinfo_cur_freq, then userspace will never know about the requested frequency and the eventual one and if they are same or different. Lets keep the behavior as is and update only cpuinfo_cur_freq with arch_freq_get_on_cpu(). Makes sense ? -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel