Received: by 10.192.165.148 with SMTP id m20csp4062928imm; Tue, 8 May 2018 02:10:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo6k2jxaW5a3UK9vMrTH3IntoNN7Z7y95eEosf2QrAuSgmHDGfTAuRFpBtbi4eiNxzW6IM1 X-Received: by 10.98.201.92 with SMTP id k89mr39083528pfg.47.1525770659335; Tue, 08 May 2018 02:10:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525770659; cv=none; d=google.com; s=arc-20160816; b=F3gZwMhIGofGFwoO+itIP9jEJdyJu9IBIC0x9SOnC3U7rtLGlGfy9vD2OHXcEbRs/S yQJKhuBgQ0/nluyWXA/v05eG1iEqBKl5bQK+1vFiec9VSTmPZcAxmAZB0ITZDXh6hlh+ iGaKyy/zg0pDTNAgi3YGpd6DwmivGNy3y+HZfsTGCBo+N9KXrxZJyR+l5/UBG50iUHdD 50za6/si95i4rDCzcJjKVwJSh5/G+Ip0qv2cG1VjkQq2/mkopnG6B5eTjW8nzJzPr8Fs 56q/01mW6l5yOEY8WQc1FrzCOMV80albG3cyo3IGrGtJkKiYHpFFOKnESRPdtslrXa3N asDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=S6raBOYn4hsf26OHzV2t8P6fVPYZcJBZEjtuE7K0GjM=; b=yd8YgPLktjGx3wNnqJIAsprL+rEP5qbf9kTdQ9SgMnjbwE3AWP4yN6yWoQ8WnnqqrE 7EUpXwqAR5pL902V0cgitCHrkABpQUHGEvZiOovAN458lJGmiBIWcV1nI9bcQIHeOiJ8 XlOK27staTZtxeXSyKdLZIMTMZA1DVwIrfkA18HHKv7RMc3sVBiyWlM1CK0QXSO+0LHA 4zonidDWqeB9hY3kwkK8+wiFLB4purgKp3VbnHnZpzcGaPoxRpBYD2ZDOsO4kBqpt8z4 IMdqIsSRZndm6cx6HT7P7x9xu9+Y3psJ9tEvWRDv8oH+uuQs8YNKGfur7yaLnVxoLkvM p5Zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e187-v6si19546468pgc.127.2018.05.08.02.10.45; Tue, 08 May 2018 02:10:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932712AbeEHJKE (ORCPT + 99 others); Tue, 8 May 2018 05:10:04 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54662 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932308AbeEHJKC (ORCPT ); Tue, 8 May 2018 05:10:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3F95B1529; Tue, 8 May 2018 02:10:02 -0700 (PDT) Received: from [0.0.0.0] (e107985-lin.cambridge.arm.com [10.1.210.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2D443F592; Tue, 8 May 2018 02:09:59 -0700 (PDT) Subject: Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily" To: Viresh Kumar Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , linux-pm@vger.kernel.org, Pavan Kondeti , "Rafael J . Wysocki" , Juri Lelli , Joel Fernandes , Patrick Bellasi , Quentin Perret References: <20180508073340.13114-1-dietmar.eggemann@arm.com> <20180508082242.bre6sjfvefhz6xc3@vireshk-i7> From: Dietmar Eggemann Message-ID: <8cf21b1a-ca6e-fed7-43c5-94c66ff5986b@arm.com> Date: Tue, 8 May 2018 11:09:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180508082242.bre6sjfvefhz6xc3@vireshk-i7> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/08/2018 10:22 AM, Viresh Kumar wrote: > On 08-05-18, 08:33, Dietmar Eggemann wrote: >> This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13. >> >> Lifting the restriction that the sugov kthread is bound to the >> policy->related_cpus for a system with a slow switching cpufreq driver, >> which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not >> only not beneficial it also harms Enery-Aware Scheduling (EAS) on >> systems with asymmetric cpu capacities (e.g. Arm big.LITTLE). >> >> The sugov kthread which does the update for the little cpus could >> potentially run on a big cpu. It could prevent that the big cluster goes >> into deeper idle states although all the tasks are running on the little >> cluster. > > I think the original patch did the right thing, but that doesn't suit > everybody as you explained. > > I wouldn't really revert the patch but fix my platform's cpufreq > driver to set dvfs_possible_from_any_cpu = false, so that other > platforms can still benefit from the original commit. This would make sure that the kthreads are bound to the correct set of cpus for platforms with those cpufreq drivers (cpufreq-dt (h960), scmi-cpufreq, scpi-cpufreq) but it will also change the logic (e.g. sugov_should_update_freq() -> cpufreq_can_do_remote_dvfs()). I'm still struggling to understand when a driver/platform should set dvfs_possible_from_any_cpu to true and what the actual benefit would be.