Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7883996pxb; Fri, 19 Feb 2021 01:37:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJyVSuhkN7u/WXlaQ8LK7jB/WkSW4Qs9UyXJ/+SoxjAqd5oBQkheVfSjmA+ELzg3doREXY4w X-Received: by 2002:a17:906:510:: with SMTP id j16mr7858855eja.277.1613727475144; Fri, 19 Feb 2021 01:37:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613727475; cv=none; d=google.com; s=arc-20160816; b=Rz7qbCKVJXZVbfdy4UYmrngrzT0R1ztiSkDb4FZ468veZcSuLJpeP3k4IixWMHp3qe DW8kDvy40IJ6WalDfao9v7jatx3Zikc8x6joY+gFoq+MQwliJ2pShWTfUTi8WjmUtnjv I3JOyvTv/2WlpASr5yu5uWTsChZtudWGGEnENKTXmdLRTt2SbM3gYdoA4/9uOr8p3hMt 9hCrKIDQc69zZmllxUYLAQNvAuBkikhGH+/HoawtKcbwXb3QCSn6It2yUU52KGKcIy1p qzgjFgUQuOfLDR3dg+Z1AHDwYWGy/eE3GPZX0bQ6umHAVX/LxEP50BbfTjP0gv3Ku3cJ n7gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=QRKFIKxvbdbgCQa2DA6d6kpnINF/wfZXSyngxZL2TfY=; b=fP5X/SbBVNhxs04HYwm7s8gqRNzoh6sN7UYlDC5XpWKyA3CphopdaSl/+oc9C7+2Mi vegg7UrJ0HFIZSxePOJxJU0En5CQBhMYVYQMvtQm2hQ0bHghZO/bQ8/60aXPDt/69ivs 5odkdJGWyOWiRZb9snNkq8+NPIbqZar4dTtGXm580QfD+/iOScvv3K5dD6H1Sh6K1Sxz uOzRlDWUyYCRWIqxCw+xTRfZIfjjPdzqlipIJXOyK2JM42zzQGgOvrH8vUIc9Q/bKdrV c/o/9sBpB3jGUw3iQ3cG/ONN9xn15qrxHrSE1Weq1mGtPYy6NRX+LIjcm3Pg9DHHummJ eq+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Mgr2pHz/"; 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 z17si6016563edm.470.2021.02.19.01.37.31; Fri, 19 Feb 2021 01:37:55 -0800 (PST) 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="Mgr2pHz/"; 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 S229876AbhBSJgm (ORCPT + 99 others); Fri, 19 Feb 2021 04:36:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229599AbhBSJgg (ORCPT ); Fri, 19 Feb 2021 04:36:36 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCAE5C061756 for ; Fri, 19 Feb 2021 01:35:55 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id t11so3541863pgu.8 for ; Fri, 19 Feb 2021 01:35:55 -0800 (PST) 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=QRKFIKxvbdbgCQa2DA6d6kpnINF/wfZXSyngxZL2TfY=; b=Mgr2pHz/EvZx6HL00ywnP4w6yT0x608sM+pL75U9Jqpocblnh4wtbuukp64ESKMDge hFuIrwQmHyNJjHlhghy97vi8XgerxOAIoHZTYuIo6B2gqNPO0sRhPbJdpke5kHVJAZM4 Mhh+bp3ijePc0Auom0Tbxl/rX5KP0GwrR03L2QstBEmFfzzKDxb/mU+peorLcox3ZZDI jFXS6QCapnEtablb7d3qxRdGA1eT5N5hIpi3Pn4Tayv/lbdrxRF+DXiOmkBl2fdMbPmk AHjQ/EPL+ac33I3dgRz6i9fhqHLjRnLtmuzCDc5bTC8VKEquCYf0SucO13RkoKZtjK2q Pqgg== 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=QRKFIKxvbdbgCQa2DA6d6kpnINF/wfZXSyngxZL2TfY=; b=Y/fHKQrOXfe2+KbcqpupxbO0KXVjfBX4wgbPAGG1rRodv/b7t9VS8jxsRiLZYxDB4Q q7lA23mYRWSADQhZusNCLUJ1q4Y8xLy7q/7nYBxTYqEb1xRJXDhWZmLk+ysNIPGqTObv TSe87vMQkITyc/xVFH38I94fZTy54KeBwZjaxx/KqfL1bWNj08lMZGqxoHSFjlWNhLAN TQxHdoknst8vXzJ5diea7kSJnHG40h8WRI3BeM2aiE/MExNcv2jzwBcVzDuo5j+owkqC qys+zKx7ECMugxMJKHshP5elJPb8b2+y6mzoCkDSYXTHYY7XUGamMzy1o59ZBRDjRa/t peew== X-Gm-Message-State: AOAM530M9nLfqpE2SF1knh3PBTmbwbU5XAOBZT1GQFH73TQd5SqQ4uii 7edxqk48WORqLfldFRd5ewP8oA== X-Received: by 2002:a63:c44d:: with SMTP id m13mr7839608pgg.64.1613727355194; Fri, 19 Feb 2021 01:35:55 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id f2sm10095069pfk.63.2021.02.19.01.35.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2021 01:35:53 -0800 (PST) Date: Fri, 19 Feb 2021 15:05:51 +0530 From: Viresh Kumar To: Yue Hu Cc: rjw@rjwysocki.net, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, huyue2@yulong.com, zbestahu@163.com Subject: Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq_update is set Message-ID: <20210219093551.bykqhjk6xvs4kszi@vireshk-i7> References: <20210218082514.1437-1-zbestahu@gmail.com> <20210218102029.syj6vkltlbtoxsig@vireshk-i7> <20210219113804.00004a7e.zbestahu@gmail.com> <20210219040933.2o5hhbjb6emf3xl4@vireshk-i7> <20210219144140.00004de9.zbestahu@gmail.com> <20210219074249.2hcwcnakihor343h@vireshk-i7> <20210219162026.00002e2b.zbestahu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210219162026.00002e2b.zbestahu@gmail.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-02-21, 16:20, Yue Hu wrote: > However, we will skip the update if need_freq_update is not set. Not really, we will update freq periodically nevertheless, around every 10ms or something.. > And do the update if need_freq_update is set. Yeah, that breaks the periodic cycle to attend to some urgent request. > Note that there are unnecessary fast switch check and spin lock/unlock > operations in freq skip path. Maybe, I am not sure. We are all up for optimizations if there are any. > If we consider unnecessary behaviors above, then we should return right > away rather than continue to execute following code. As I said earlier, we may end up updating the frequency even if need_freq_update is unset. -- viresh