Received: by 10.223.164.221 with SMTP id h29csp1226300wrb; Wed, 1 Nov 2017 12:36:32 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TK4kjJ/+Qg6kaGQ/8pbcewr10vyS4QqBKmIHY56E36aDemzLe5ATX0Rj9lG8KzrUxhdI5u X-Received: by 10.98.224.194 with SMTP id d63mr966555pfm.21.1509564992285; Wed, 01 Nov 2017 12:36:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509564992; cv=none; d=google.com; s=arc-20160816; b=VA3PLVt36K5VGRMFBrqU5fVqBTOv7FLengffsKdz8WrKbXtupUamvhyk4bZuoisS5i f5CFFwueNo454cVNsIYNJsOpE/OWOdcg05vkuq54iKJlj+Vqx0ywWGle8g4K1VJtQV1l RaYQsdgtflK2X8M6ITXCDZNPU5jtA+7CDidxrr44M/o9tUp8ZRwBFLNNY6uSv4YiDcth X0zSI6s3msfe522YSOxrdLXODAiLRizARR4FBJtGaCJ4XtJSwxZBbAyVwEEV7S5db83i 2VDj8XAroCRE1TVwZImtLPTs5qX8fNA/iGDneATQMa3rCUsoTjPwzK26C7TraaV3CEXK B1VA== 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:dkim-signature :arc-authentication-results; bh=XonRt2AJb4d/la8pJNcjfy0gyXyGXlgE739hedW+pmo=; b=dzVig0m/mO56ThlnE8wwxAJAEVw4kCTYBxMHVKW9gkF2XUnf0D1tv4n0lalbfhAm+D DbDQ/Erbzw0c3RrpMXTG/qrgI2UIS83/1W+34HEdBAif7hCGlQ8zk1wTjzdLWg6fZJ0E UQZQIHJlt6ebUOZhSul3he03QLavucsDkE+vl48w6iwGdA41XZy2hzGZ6tA9tDJMg1j4 1oLDzdZaqFCnqYviL7ktNRAeu2bZYyabrgdGtjAb/yWhyWE2cCJBzyBhDSwo4KzrMuOl 0d2bUQUGFExxsT811sjLEcG6WOVFIUCnKYWRZl9eBbm3hilJ6TqfMlsGbE7mk8aPYq/v Td4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZSq8JvVm; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n13si1709855pfb.79.2017.11.01.12.36.18; Wed, 01 Nov 2017 12:36:32 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=ZSq8JvVm; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754971AbdKATfn (ORCPT + 99 others); Wed, 1 Nov 2017 15:35:43 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:53422 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbdKATfl (ORCPT ); Wed, 1 Nov 2017 15:35:41 -0400 Received: by mail-pf0-f169.google.com with SMTP id t188so2701682pfd.10 for ; Wed, 01 Nov 2017 12:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XonRt2AJb4d/la8pJNcjfy0gyXyGXlgE739hedW+pmo=; b=ZSq8JvVmJu2F31BhEAJv9H8yXddQ4Ei7RbqXyOjhNP3LIBptdakUkbBVT2voZgZdaD 9c314hUVx0o11rezhjpn11HpdzR4MPARin16x3fBvjeF/PKpnO3k1r/+HNo9zjIzOFiJ S3ZhA5ujxcILXVZ1kZaPm/3vMsIjct3HTFV1tclhb8BIzQbOAq/vd9Q5dGjLRoS7RMe+ BluMu3fTuvz7eOHI3N3zBORjm3I+pABqo5s/whyN9vvUt8rBqG2x40NzZm1K2Bt0Q1jC JYj43bcggnsbf0VOjBphhD3SeJDCddHOIuoavX5ViII5FVtquiTiR/m+JPFCfHmlDzjk FUTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XonRt2AJb4d/la8pJNcjfy0gyXyGXlgE739hedW+pmo=; b=jRCAGQ4dXqaVcbxCkUAi/WHKPWzm7C6GIrmSIfedxCyQ0K68B4ZS93G2wfJx/TR4EF ic5qzasLs7S/ZHI+84s+T8mFrgoa64fHiwYdLXNSfx642bs5EaXVjnzGlhWR8c0giWU6 KRdGoTrQIlvskgpzWo8nSzuP4YORs6zSvtod7bqPd8k2uKa5nU+OYPda3ovYoPzwb8cw qM6EofeRkRsmuuFMjdOEECR3hv2VmfgJo509hP0Fui65WYzBf8NCK+MsyVHsX/19wVBb bv36vtY3mLKQZNpXe49Oxl+XIqyY2OzuorINuRipHqAbMuyg42yI/+SnwXPH2rolp/d/ TTLg== X-Gm-Message-State: AMCzsaXq4mFthNqfvliHEtp75xHSQb6QPIbESvvEW1hNhGKt1QnJsu+E TeYTIrhb+MtprbwYuHreJCI+gw== X-Received: by 10.99.110.6 with SMTP id j6mr949860pgc.246.1509564940122; Wed, 01 Nov 2017 12:35:40 -0700 (PDT) Received: from [192.168.1.140] (cpe-70-95-104-248.san.res.rr.com. [70.95.104.248]) by smtp.gmail.com with ESMTPSA id v15sm2236643pfa.50.2017.11.01.12.35.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 12:35:39 -0700 (PDT) Subject: Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle To: Joel Fernandes , Viresh Kumar Cc: LKML , "Rafael J . Wysocki" , Ingo Molnar , Peter Zijlstra , "Cc: Srinivas Pandruvada" , "Cc: Len Brown" , "Cc: Juri Lelli" , "Cc: Patrick Bellasi" , "Cc: Brendan Jackman" , "Cc: Chris Redpath" , "Cc: Atish Patra" , "Cc: Dietmar Eggemann" , "Cc: Vincent Guittot" , "Cc: Morten Ramussen" , "Cc: Frederic Weisbecker" , "Cc: Thomas Gleixner" , "Cc: EAS Dev" , "Cc: Android Kernel" , Steven Rostedt References: <20171028095941.4773-1-joelaf@google.com> <20171028095941.4773-3-joelaf@google.com> <20171030120709.GO4240@vireshk-i7> From: Steve Muckle Message-ID: <6ed7d641-4fa2-77e1-9294-64d51193c786@google.com> Date: Wed, 1 Nov 2017 12:35:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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 10/30/2017 12:02 PM, Joel Fernandes wrote: >> Also, this more looks like a policy decision. Will it be better to >> put that directly into schedutil? Like this: >> >> if (cpu_idle()) >> "Don't change the freq"; >> >> Will something like that work? > > I thought about this and I think it wont work very well. In the > dequeue path we're still running the task being dequeued so the CPU is > not yet idle. What is needed here IMO is a notion that the CPU is > possibly about to idle and we can get predict that from the dequeue > path of the CFS class. > > Also just looking at whether the CPU is currently idle or not in the > governor doesn't help to differentiate between say the dequeue path / > tick path. Both of which can occur when the CPU is not idle. > > Any thoughts about this? Also if it really is the case that this bit of policy is universally desirable, I'd think it is better to do this in the scheduler and avoid a needless trip through a fn pointer out to schedutil for performance reasons. From 1582711286139098451@xxx Mon Oct 30 19:18:23 +0000 2017 X-GM-THRID: 1582495113361800894 X-Gmail-Labels: Inbox,Category Forums