Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp262559ybt; Thu, 25 Jun 2020 21:46:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwv20pgjBvHtqCia7fBk4v/orICFkj7oX3SdfCH0KLne9Hxyv+mtgr83Eh3GVu5rpAsgkU1 X-Received: by 2002:a17:906:fa15:: with SMTP id lo21mr1052912ejb.156.1593146780158; Thu, 25 Jun 2020 21:46:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593146780; cv=none; d=google.com; s=arc-20160816; b=dcdQQa60OZ0rM3cPKdBDIREzFJ9yRqKahNSu3yWBgN4qdXKc0Z2rIWSkThYeZPZ+VW 6bQYwOPhvWFQYFSMpYEe/ZqgwkwPLBBJSA8BekkzF8prKwmXsaorBBE0BrDz51QE0n+C 506tWpB/FXlnsYqjmTvJpB4bXpzQvML/nfONT5M/ofBE2YD2n28gelWnBYjcDYTy8Oxl YOY5g0Ui0Dq8Njq9hS7nL5/e7KNhRUDBA8ZXaLf/m/2FqZT45JieDxswnJjuaI7Hu7TX e02ePb37ZHnT0On46dEgIllheu+yjv66sCjTtPttwzHKH0vaoxt/gDcOrcPi+GIvbT1X cRKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=sMIkTEY7xPHCqbn5JKjvRxEVOX+Rdd4R46yFsFdge5A=; b=C/eQDSwwGAnHt1yGxZrkNPIWTsfKNZldTP0eKmM5m3QMoj3Hsgt2SPCEHLfeOHyF0B DdNklnmxUULhVwH2oKaJTzURRwFp8qlOhBIdreetvX4P8xHIZxEmq01xqsjFcadzgo9D FcAcsgJOnoT/aQrajO2TVYeXPodPwfb62a3+wN3SX4JKtgWnqIhnrfytCoeJxoABVGpX 4d11PxGOCoMKDUbOHcQiux1YRniYpsNDIM4TorDGpPZTEtqIVqCLD6SQotc2S5LvcKmP MsH+knSzuTfbZil22KPWT+6eYk9BDFEY9OuJm2EZ15yKvgFc/AvOU6E/sOS6IOEa2W6d XxIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=H2TZ2Zav; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id du17si19793385ejc.248.2020.06.25.21.45.57; Thu, 25 Jun 2020 21:46:20 -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; dkim=pass header.i=@linaro.org header.s=google header.b=H2TZ2Zav; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728110AbgFZCcZ (ORCPT + 99 others); Thu, 25 Jun 2020 22:32:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728105AbgFZCcZ (ORCPT ); Thu, 25 Jun 2020 22:32:25 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2730DC08C5C1 for ; Thu, 25 Jun 2020 19:32:25 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id bh7so3696328plb.11 for ; Thu, 25 Jun 2020 19:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sMIkTEY7xPHCqbn5JKjvRxEVOX+Rdd4R46yFsFdge5A=; b=H2TZ2Zavm132TIF8kv/1qMkgUjcXDU9hqjRnSmHgwOjAq7BbOdbWyxlLmnF/CcbuSZ XE4B1hNibOuLzFzrwkaqBgaIK6yEhnbL6Xv9XoGXyOpjO3KA71h82XQUVVMR/80L1/I+ X7wY2+/c70DpnE6YMj6U1kekSqKVpAl0+1qoMR3IQ0tQfo5wD5mRiNdpeIyqzLAi6t0V kqrWt/BfTz8yvRfXjI/l0ApUnsM/mAyoiAiCvJ+IV5hJPcMTOl7hQfzKidM/tVR57jwT YWZyWkaoROvm2JByKSqT2sww40xFchead619IWL70+SYCcFBP4iyYE3n8t12qODhxE1t watQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sMIkTEY7xPHCqbn5JKjvRxEVOX+Rdd4R46yFsFdge5A=; b=Uge63FD3zwAN62IE3p9x7GG5xQjz1IPtyULnEWDyjdVJJgFoOMzMmVDj9M2WMtfPli fJcaFa92rZGtHLcOQJbbhsf4Rqa2n9VbBHcPvtqp5Yd9On0LLIQ817DLhev7F+uDoMgK v2ctE/z58hoTgD9cHx5TH0mDZwV9VjRm94FwRYb4ANifrtEbAZ/mch/dZVkqUA5RU50f G2yf4Go6yaqtYSrF6LwWOtqw7f7SBiFXpetIBV1nFvKw6214rVJXZ7PBtgHp6rfcXbU6 moPHoDgSma/fVBB/mc2nPNuHqRhVYWHX4BQtEc2gFdl9wNv6Be7j0sgIecc8YtDMABtZ mcTQ== X-Gm-Message-State: AOAM533ljP8obPFelfkxavL6JzfBOgnmYMsscZdFDpUilVcq2a3BSub7 hm/9wWxC5ORK2MpkGw8UGKgQrw== X-Received: by 2002:a17:902:ab8d:: with SMTP id f13mr674057plr.119.1593138744407; Thu, 25 Jun 2020 19:32:24 -0700 (PDT) Received: from localhost ([122.172.127.76]) by smtp.gmail.com with ESMTPSA id gq13sm6079747pjb.7.2020.06.25.19.32.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 19:32:23 -0700 (PDT) Date: Fri, 26 Jun 2020 08:02:19 +0530 From: Viresh Kumar To: Wei Wang Cc: Wei Wang , dsmythies@telus.net, "Rafael J. Wysocki" , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , "Joel Fernandes (Google)" , Linux PM list , LKML Subject: Re: [PATCH] cpufreq: schedutil: force frequency update when limits change Message-ID: <20200626023219.wvhzomwzlw24bzrv@vireshk-i7> References: <20200625064614.101183-1-wvw@google.com> <20200625102305.gu3xo4ovcqyd35vd@vireshk-i7> <20200626021428.tnecyy3wt42slvik@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200626021428.tnecyy3wt42slvik@vireshk-i7> User-Agent: NeoMutt/20180716-391-311a52 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26-06-20, 07:44, Viresh Kumar wrote: > On 25-06-20, 13:47, Wei Wang wrote: > > On Thu, Jun 25, 2020 at 3:23 AM Viresh Kumar wrote: > > > I am sorry but I am not fully sure of what the problem is. Can you > > > describe that by giving an example with some random frequency, and > > > tell the expected and actual behavior ? > > > > > The problem is sugov thought next_freq already updated (but actually > > skipped by the rate limit thing) and all following updates will be > > skipped. The rate-limiting thing is specific to android and not present in mainline. Even in android I see next_freq getting updated only after rate-limiting is verified. I think you maybe trying to fix an android only problem in mainline, which may not be required at all. And I am not sure if Android has a problem as well :) > I am sorry, can you please give a detailed example with existing > frequency and limits, then the limits changed to new values, then what > exactly happens ? > > > Actually this is specifically for Android common kernel 4.19's issue > > which has sugov_up_down_rate_limit in sugov_update_next_freq, let's > > continue discussion there. > > If it is a mainline problem, we will surely get it fixed here. Just > that I am not able to understand the problem yet. Sorry about that. -- viresh