Received: by 10.213.65.68 with SMTP id h4csp195665imn; Sat, 24 Mar 2018 18:40:11 -0700 (PDT) X-Google-Smtp-Source: AG47ELsLY48ufvQX4cFIj9luCz2A1E9bEEC45jwAsgKMDlws5z4Q7YfgTzU9A6K8IVrKzXYpxLVo X-Received: by 2002:a17:902:bc04:: with SMTP id n4-v6mr35103754pls.97.1521942010976; Sat, 24 Mar 2018 18:40:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521942010; cv=none; d=google.com; s=arc-20160816; b=u27ztyt8SlyyOrG4VH9gklyJ5f5lGLIKuG9OsKDjX8wSGAts8WWl5TQyJXgucRXmrP 6A9JC9xlhgpeyxMbOt4i5kxKBUNAwvdFI27Ne//3wVD0+TSdCLv8b2zdMYhy+LD5t45z 8G/ksKLKTq8h9+ToSk4K0RvxA8fhUT3WZwtn+JGA5m0W2WoA/pbDAC/nffATk4UyQIc3 GZz5tzTtSSlM0R576hNlVeMwqsBfZtIJUxwPQJTJHH+LsfH0sUvBotgKVEyYQom5uuPS LkpSc6AKYQDjSfL7BjQAMZYQEorE019T/WpScOv7wKlEH7ciiT/dOe0QBfD2VN9d3/uE agCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=HKQSdeDW7ZVt+BkuuCS5h8898NRN16pfnKsHM2Y7oUc=; b=RntnXQVRK3gveN840907TrsZbYUBYAJMbh4jOkRl4zpCWDW7gcclFRPG4ChO7r9DhL id++IBKEW3QJxfHWQXKw8KUkNWhW2FPt0NGnCYChwKr1lmuBwYV7n6t791PUifc6MQrR lJoVzuCJHkTGLm41/QTgGvRtzGFlz8KymFW5+NKcXNIjd+isNKYp5mu6jxERQFT7DVlV pYAMn1p6anoYv1vqre08q0hP5n+hnAGViFzV1y9m48OVkhz65KpBBZ/booq0o8nH06mp Ufqm2M0v7m2f0I0scvJgHz86jrIFCaIJ47pWHc93haU6PTxeEbAF+drke846azmlAqrD LJKQ== 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 x33-v6si8604944plb.512.2018.03.24.18.39.55; Sat, 24 Mar 2018 18:40:10 -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 S1753131AbeCYBjH (ORCPT + 99 others); Sat, 24 Mar 2018 21:39:07 -0400 Received: from foss.arm.com ([217.140.101.70]:60670 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbeCYBjG (ORCPT ); Sat, 24 Mar 2018 21:39:06 -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 83C2380D; Sat, 24 Mar 2018 18:39:05 -0700 (PDT) Received: from queper01-VirtualBox (unknown [10.37.8.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DBBA63F592; Sat, 24 Mar 2018 18:38:57 -0700 (PDT) Date: Sun, 25 Mar 2018 02:38:35 +0100 From: Quentin Perret To: Morten Rasmussen Cc: Joel Fernandes , Dietmar Eggemann , LKML , Peter Zijlstra , Thara Gopinath , Linux PM , Chris Redpath , Patrick Bellasi , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Message-ID: <20180325013833.GA1803@queper01-VirtualBox> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> <20180323160059.GQ4589@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180323160059.GQ4589@e105550-lin.cambridge.arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 23 Mar 2018 at 16:00:59 (+0000), Morten Rasmussen wrote: > On Thu, Mar 22, 2018 at 09:27:43AM -0700, Joel Fernandes wrote: > > Hi, > > > > On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann > > wrote: [...] > > Is it possible that before the wakeup, the task's affinity is changed > > so that p->cpus_allowed no longer contains prev_cpu ? In that case > > prev_energy wouldn't matter since previous CPU is no longer an option? > > It is possible to wake-up with a disallowed prev_cpu. In fact > select_idle_sibling() may happily return a disallowed cpu in that case. > The mistake gets fixed in select_task_rq() which uses > select_fallback_rq() to find an allowed cpu instead. > > Could we fix the issue in find_energy_efficient_cpu() by a simple test > like below > > if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed)) > prev_energy = best_energy = compute_energy(p, prev_cpu); > else > prev_energy = best_energy = ULONG_MAX; Right, that should work. I'll change this in v2. Thanks, Quentin