Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4728996pxb; Sun, 14 Feb 2021 22:36:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJxGvXSvBDGA8PyNLkK+zAcPFLva6M8V/MLYU6psPTQrnw1VMpk+w2G+uVI/Fqy6SNZjYWgz X-Received: by 2002:aa7:c84b:: with SMTP id g11mr14087729edt.169.1613370968995; Sun, 14 Feb 2021 22:36:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613370968; cv=none; d=google.com; s=arc-20160816; b=Rg2LpbUMx+33M//8aLNGljVlBp4kpaGy6YPZFtCLkWDH7hUQbHcnFNyv6mclJmq7Gv 2Nh7ePPZSv1dgF8M9BOWMaFCA6PLhjvunX9Pj1VqV9Zb3MfetA5dBiH5qQpixiQdZ89J jsa3IrnsOisSzGYwix0tbyhWzor7DTRx0G5eLS6qFs/6ZAEiFP+QAvEfkWqRhYGtB5aI G6+j1gGIFhYlpoEEDCT+UdJazkx7kc4R7bCBnNIuXQQGI3b6Zn5l+Z3qmpmG/nq7hlTW usp0btrGo7cg2ihmX0BqqYc6xJzAmcNy/s6rGnFhXzi06YEXGFvbeS3qOInE5ewMEKJW QhiA== 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=zrrEJXp5mV7UerRAeRKG8eH9oggn9kYScOtYlCg1RtE=; b=xR3sksitYIBfiQye6sSCM9coGUyRRLkfDdzObzevlDwiAklMC4XFwoms1IbPgtFlgA MC2QV5IknmZN93GgvKRGVgtJJlTAGmxoDeXP9DPeocDZxSiQ5+Q9pnMCuRzZndboqpxa N73I18Xskvh5yUkj914rasaFSN8DxXka+p9Ed7he/WoD9EMXVIdLE3vyuWCKMwEmE2SO WG17C1WT+N1xcfD/Fr1+QK4ihvBrywZiFGL3LRE7YkyxVaWyGVxHK08vfzcYm92jMk/T sK1h3BnKduUHOPXl/aP7qxusokqRb6viPsYAAJXh83oohd3kYyyk1ySxIg+9JBsNA8x/ PXMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=c8g5I91z; 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 mp41si2788358ejc.10.2021.02.14.22.35.46; Sun, 14 Feb 2021 22:36:08 -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=c8g5I91z; 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 S229922AbhBOGax (ORCPT + 99 others); Mon, 15 Feb 2021 01:30:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229552AbhBOGaw (ORCPT ); Mon, 15 Feb 2021 01:30:52 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2BB5C061574 for ; Sun, 14 Feb 2021 22:30:11 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id f8so1565789plg.5 for ; Sun, 14 Feb 2021 22:30:11 -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=zrrEJXp5mV7UerRAeRKG8eH9oggn9kYScOtYlCg1RtE=; b=c8g5I91zu7IKDPWRVPgs/cED8NOhfy+V9BA2gFo06lfye2pSAvDAkGRhhTmEnlzw5B iTSU2NuOPWQYxgSUQ52oGuyUaGQelQpU3wt851sbECfNqYZMeqyDFT0FSqtnbyE1wxBx HtWsOszmdOnFkKq5Do2Db0vtr9W6Ep2QcKKeqS+h+rN6QLQPyRhRGg5KrzA74AE3ZHQK No9QT1nHtmV1lziAKaQ+wxdZNUGiB/0al++tnnbRo6gdkwtbMS9+mXrFWVOBziFxcTcU /kRGQo2pP7ia+AyXJyutfnWOgoRM+QufF/ERsq4tAEtxy5qS7xD2uAyH0vbQP3E5dtlu /f5g== 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=zrrEJXp5mV7UerRAeRKG8eH9oggn9kYScOtYlCg1RtE=; b=s/QOdAuJLpxn6wrWz3bo+ZUdNlTbiYlLjvAje+mlpr3toE7DG29+1+bkWvoNasLGWb x5JX16rzEjPDRNutUsFsSJzrqsITK0mdswsuHmppYV88eMfy2og/Lw4ZeQWbF8CsW8XQ BmK03KpAWxq524xIIOfaQOzq8k+0ks5AYJfXaD7Llm03r5WtHaD+s6tXs78sdInCN1SF g8EmkMwCHgiARXYXl0f/rCvOKkxPel2KH78BFcqKj4h4Mn7OTc5CrDW/TpWRH1UijKth 4Orr8kn5nuXqcWL4fpL3PXD4Zgg4YnDNfR2jp7cEw/gHNK43tEHA1tJnIhhngAHPWaa5 Gc/A== X-Gm-Message-State: AOAM532AZA5mVFdMUaDHnn7ToYPC9xxKPnP4Gds71yDLk0rriz8ISA5y PkkLh7b5ZuEV50Rcy7oKP29t9Q== X-Received: by 2002:a17:90a:8e83:: with SMTP id f3mr15278354pjo.70.1613370611311; Sun, 14 Feb 2021 22:30:11 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id h8sm15462226pfv.154.2021.02.14.22.30.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 22:30:10 -0800 (PST) Date: Mon, 15 Feb 2021 12:00:08 +0530 From: Viresh Kumar To: Yue Hu Cc: "Rafael J. Wysocki" , Yue Hu , "Rafael J. Wysocki" , Rafael Wysocki , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , Linux PM , Linux Kernel Mailing List , Yue Hu , zhangwen@yulong.com Subject: Re: [PATCH] cpufreq: schedutil: Don't use the limits_changed flag any more Message-ID: <20210215063008.hsdkrs4bw7wt3wye@vireshk-i7> References: <20210208030723.781-1-zbestahu@gmail.com> <20210214114421.00000550.zbestahu@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210214114421.00000550.zbestahu@163.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14-02-21, 11:44, Yue Hu wrote: > On Fri, 12 Feb 2021 17:14:03 +0100 > "Rafael J. Wysocki" wrote: > > This may be running in parallel with sugov_update_next_freq() on a > > different CPU, so the latter may clear need_freq_update right after it > > has been set here unless I'm overlooking something. > > Whether this logic is also happening for limits_changed in > sugo_should_update_freq() or not? It is but it shouldn't have any side effects as we calculate the next frequency after cleaning the limits_changed flag. Your patch would have been fine, but it is not anymore because of commit 23a881852f3e ("cpufreq: schedutil: Don't skip freq update if need_freq_update is set"). It made a considerable change after which your patch adds a bug. With 23a881852f3e, need_freq_update is updated/cleared after the next frequency is calculated, while earlier it was cleared before it. And so even with the race condition taking place, there were no issues. -- viresh