Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7807843pxb; Thu, 18 Feb 2021 22:46:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgGUqjjtargUSTAXhc1IURz0yAPEuedr12dwIKVcAFZmTCRJN9Qlp0TKlyieFdzTLCsQ/e X-Received: by 2002:a05:6402:1589:: with SMTP id c9mr7895060edv.282.1613717179913; Thu, 18 Feb 2021 22:46:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613717179; cv=none; d=google.com; s=arc-20160816; b=gMKm6mAB1qfiiKYtCarjFWMiW49DuuZo4Q1vtCCR1JGprEmWZCaM9Z3OegjFGE7cQc QxzMtPM1DQJb+7I0buJDvIOCB/iE5m1TVJ0I0+Zc8yA8AL1hN7ICVYUtVkLmh4TBukho A54HR8uiWbT15AnSYHwFCBtw8cSDx8mzDuM9WABp4m1XFe2qP9kRWV4SFc/EPgLuTJyK YlC7vayfADj6eD5qm93icEMDJebW/LH6SYrxUBI/ufeI8LVnjmEjU34uITTpIpH3MojJ oVLe5FC8vG8aKhmA/YQZj3NVN9IMECWYzSF6ZJ/fBKdfOvUYV0UwRb0rmHjZ7eGDclFw +9Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=irQ99fwvyT3B4IXadbKZ2UTqLLi0pPWPv3qC3rVkQS4=; b=h5HvPCGkhdAw9a7u/fpyezSyTVmSpolmguY38CEx53G/Jl1VTEuYWkyZZO0AIp6uxa AriUxnYVcjqeMGwFbpX4H2DaQQTzlu5bEitCZpX1JWrLA9gfkrhTVjVmYuuFEZl2uXmp sFqbDHI8HWrqMUdSkRhddLUWhoO9r/WaVKN3P2wv5kCFVPsWylTDmUq8rLza4cAZ50LM ZhKZlGxEII9idcmEx2VwziHkBmi957VlTRDvHCkfopmGZwU2X801v0ycSHnes1JCsjlO fJKFcO9bcRcQiUoFA3ChmSu5XvnR1VDW51ZXI9DyanjT8QZVquXgYX7sFise2J+qsQiq u4UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KUWkEvGk; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z26si5154630edi.376.2021.02.18.22.45.48; Thu, 18 Feb 2021 22:46:19 -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=@gmail.com header.s=20161025 header.b=KUWkEvGk; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229546AbhBSGmb (ORCPT + 99 others); Fri, 19 Feb 2021 01:42:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbhBSGma (ORCPT ); Fri, 19 Feb 2021 01:42:30 -0500 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40726C061574; Thu, 18 Feb 2021 22:41:50 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id f8so2826313plg.5; Thu, 18 Feb 2021 22:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=irQ99fwvyT3B4IXadbKZ2UTqLLi0pPWPv3qC3rVkQS4=; b=KUWkEvGk2DoZBtwIH+TOaLF02h1TEf8NR2b33z6uu+BUZpu43B6bNPgZgymYZhQmOW v9X8FtgFDnUiv35ItVlfq10yNeNKA7gLk6GLdn2YVXnKjLeKsJOcUe/6vj67Pk2rJW6e vKVhvlEdLXIDSeDLBvGeypdwVfxZRR1eeYem8WkVaCVjQOpPOpQsioYvflVDzF1sBceX SfkoEeJrKjEtjzmg+lGOoJf/FJBD8HJF4gb35GRvastjZESIwidOAaYwZ8h/wOQJ9OR8 020Vj7k7EEqYE4P8jTLPCZ9NvU3MfjZNtQwRqucJDP86Gf+dUqygguYP023+Zyjg9mRX E/Mw== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=irQ99fwvyT3B4IXadbKZ2UTqLLi0pPWPv3qC3rVkQS4=; b=MiyapQl2Xhf2dp0FMow9wORh2ipJ8O7UBdcr2f1VbJ4qxoxD0uLwlOHNlZTiD/nO8m pr5JuqkCIsz9qdZ8OsupwBg9e7+CLiTQhQAwoMNWiYvwiCbCkc0TnN8D6s+lnX8enmdm uA4Z5V8K3SpEYOM11TiCO90McfvDJ0K9Zu0/Cg0ZeooYKIHFktd8nsPnk54GW0Zw3Qv6 xxhswVH+UEuZuvYyeRrNMncwHj0pMUBwE+GvDXZlNpORXUL64yl9ASqz8br+OCYJKlo/ fpH+ITMeiUp/npGyPXmBrSgbwFwdK/YUdHwausTZb0RE/onEYCMA5QCMQBJLsfPlAg/C sV/Q== X-Gm-Message-State: AOAM532SDaWkU1CDzTOYjq0ifbko/qjqA4S6oZAG/5TW7HF+3rp6nCX6 32pYZnQv7Ywye8owcRKL/Ew= X-Received: by 2002:a17:90b:4c43:: with SMTP id np3mr5249398pjb.33.1613716909692; Thu, 18 Feb 2021 22:41:49 -0800 (PST) Received: from localhost ([103.220.76.197]) by smtp.gmail.com with ESMTPSA id g19sm7371936pjv.43.2021.02.18.22.41.46 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Feb 2021 22:41:49 -0800 (PST) Date: Fri, 19 Feb 2021 14:41:40 +0800 From: Yue Hu To: Viresh Kumar 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: <20210219144140.00004de9.zbestahu@gmail.com> In-Reply-To: <20210219040933.2o5hhbjb6emf3xl4@vireshk-i7> References: <20210218082514.1437-1-zbestahu@gmail.com> <20210218102029.syj6vkltlbtoxsig@vireshk-i7> <20210219113804.00004a7e.zbestahu@gmail.com> <20210219040933.2o5hhbjb6emf3xl4@vireshk-i7> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Feb 2021 09:39:33 +0530 Viresh Kumar wrote: > On 19-02-21, 11:38, Yue Hu wrote: > > There's a possibility: we will use the previous freq to update if > > next_f is reduced for busy CPU if need_freq_update is set in > > sugov_update_next_freq(). > > Right. > > > This possibility would happen now? And this > > update is what we want if it happens? > > This is exactly what we want here, don't reduce speed for busy CPU, I understand it should not skip this update but set the same freq as previous one again for the specail case if need_freq_update is set. Am i rt? > but we also need to make sure we are in the policy's valid range > which cpufreq core will take care of. > > > This is related to another possible patch ready to send. > > I am not sure what's there to send now. I will send later after figure out the doubt above. >