Received: by 10.213.65.68 with SMTP id h4csp1011120imn; Thu, 22 Mar 2018 13:21:49 -0700 (PDT) X-Google-Smtp-Source: AG47ELtVdRF1harrfNCZP08KK8x+Gi8TNaZAzWV9TzjBFsZY8XFZe9yaQWkkx68KHLOVEdcEZX3w X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr9559069plb.224.1521750109636; Thu, 22 Mar 2018 13:21:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521750109; cv=none; d=google.com; s=arc-20160816; b=tHQtrnppnqtOcscTVkdBgl5mZcX/0CzD2y7XjgAOGGBBVw3MZVmdDfQ1oa/tqvF9h+ 4KOFTo+7JxEvMWmaL0T9d6BpONvv+U2Zea+2x56unsEGJXW/XEpp6Hjnw1+bVAM4g84h jI5G55lr0hKUBGdM11KdJxVgWUjlwT0WQuznPc63zTxJmPdXs+LIuPQp3Zg7IjR/svJR 57Z6AxTzoYUxOZLw31iv1kF+xFGDL9Hddy2WnkNjJFVpURwXFm8C1UyJxqh3f1erUITL j3oCGelstLPen7PaaKKB4uE3osFoiS6swXscyBfThskKufhLv4+6fRqzRH3Ajv9SVVMm 0hoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=jXisGoB0QRA+h0PTAXCb12OJPqsFTc5YWtKlu2okzCM=; b=pIYU6lB6bQvohCa6eIihScqC+egUPEs7V73hGCKeSMbtazCR1APNwkMMEZkqk4H4td fK+E9YB/89rZ0Bq0CyEXnE/qATZzunw8hpYl03YI9H7OFDqRg93IU/jbLyLfNquEJnif gXHkfLm3W910HcWL0Q7aT+1R+BAHAk87zlb20vIT9zbNEymOmPb/Hu7c6QdTqbkmE0CB cMRUdZk60O3a5djKicRBsUtgT4TbOpFFR2Ld4fPBGmRheeGnomhSAP2RfBviL5Hqi7tS 1HCY5pZEGJfNxire3MZ2skNVw7vzPiALyVN73y+vRGqlTaaVUYQzZm0W1Rbm/vHD8CGZ FARg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jFEAmtiD; 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 m10si4934438pgt.292.2018.03.22.13.21.34; Thu, 22 Mar 2018 13:21:49 -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=jFEAmtiD; 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 S1752004AbeCVUTG (ORCPT + 99 others); Thu, 22 Mar 2018 16:19:06 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:36569 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751819AbeCVUTF (ORCPT ); Thu, 22 Mar 2018 16:19:05 -0400 Received: by mail-it0-f67.google.com with SMTP id c1-v6so11818159itj.1 for ; Thu, 22 Mar 2018 13:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jXisGoB0QRA+h0PTAXCb12OJPqsFTc5YWtKlu2okzCM=; b=jFEAmtiDOiwdKqhwnikERhUIzXsUBYEo+J/hbOLbeE6nlgNb95ZJZKH/FbPWrcmR9+ v6e3+C/0rQVa1d2E0Wwd3XwnUi7YYmX36NECpHazErP0z6wDURO3Du1hWZJOFHIQ+jH9 RRWPD2DuOfS4Hg2v+rOXfFWRfVT/o9HTH2tx/hUeTm49CLWOVsNjU8If863JdWuYKUmo 612QnZB8VlKQ7BPzSUdWTujQQDgRj+2N4oLD8yqkASrgQ3dRNxWclS91z9YEcA6Ya2zy jA7mJ+2j+3wC5pXFImyg0G4oZLZ3hK4THRAYKTfANm2HHybt2Q/LYQ/kw+5KgcNr3PhW ns4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jXisGoB0QRA+h0PTAXCb12OJPqsFTc5YWtKlu2okzCM=; b=UxGp/2xMIF1Ajk4z7t5mX7/tr7h3CkUDDRuiAioxykzWZk6eKKxNHaQf9u5PvLeR+7 eKofHV1VBPdr5oJH14yDdjIJQKlziEjMXoXFJX4IwcPy4e5bo8j5B1b/qiuit/r6d6JG jlHH8YmE5ksmWy7SCtCpQsv4LgPobz1UJz57Qw0IWOu6sYRnojZOhhJaYuyGHgK55whb 4q74f5PvGQKk7I8a8n7IjQo1tu9FqMdAOPNkaVZQcAJwlQ0drYVs9Vo628uB8CwQ3Gv/ Tn0o/Nl4Z4Jetfjo8oS9EVz5dIFwqiLROWTo3rri6WcFIzhbG42dzSISGBMoLGCakiy7 GJ6g== X-Gm-Message-State: AElRT7EhBbQmaxPzMnBkbyGaHskVjN+5eiy3Dj4xmwxIKe9wgpnrIa1J 4VDhInehXGEL3OrFl9OkMSlAv9JT8yfSdo8PhiBt8CuE/vY= X-Received: by 2002:a24:9184:: with SMTP id i126-v6mr10905281ite.41.1521749943743; Thu, 22 Mar 2018 13:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.158 with HTTP; Thu, 22 Mar 2018 13:19:03 -0700 (PDT) In-Reply-To: <20180322180623.GE13951@e110439-lin> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> <20180322180623.GE13951@e110439-lin> From: Joel Fernandes Date: Thu, 22 Mar 2018 13:19:03 -0700 Message-ID: Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up To: Patrick Bellasi Cc: Dietmar Eggemann , LKML , Peter Zijlstra , Quentin Perret , Thara Gopinath , Linux PM , Morten Rasmussen , Chris Redpath , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 22, 2018 at 11:06 AM, Patrick Bellasi wrote: [..] >> > +static inline bool wake_energy(struct task_struct *p, int prev_cpu) >> > +{ >> > + struct sched_domain *sd; >> > + >> > + if (!static_branch_unlikely(&sched_energy_present)) >> > + return false; >> > + >> > + sd = rcu_dereference_sched(cpu_rq(prev_cpu)->sd); >> > + if (!sd || sd_overutilized(sd)) >> >> Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here? > > I think that should be already covered by the static key check > above... > I understand there is an assumption like that but I was wondering if its more future proof for checking it explicity. I am Ok if everyone thinks its a valid assumption... >> >> > + return false; >> > + >> > + return true; >> > +} >> > + >> > /* >> > * select_task_rq_fair: Select target runqueue for the waking task in domains >> > * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE, >> > @@ -6529,18 +6583,22 @@ static int >> > select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_flags) >> > { >> > struct sched_domain *tmp, *affine_sd = NULL, *sd = NULL; >> > + struct sched_domain *energy_sd = NULL; >> > int cpu = smp_processor_id(); >> > int new_cpu = prev_cpu; >> > - int want_affine = 0; >> > + int want_affine = 0, want_energy = 0; >> > int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING); >> > >> > + rcu_read_lock(); >> > + >> > if (sd_flag & SD_BALANCE_WAKE) { >> > record_wakee(p); >> > + want_energy = wake_energy(p, prev_cpu); >> > want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu) >> > - && cpumask_test_cpu(cpu, &p->cpus_allowed); >> > + && cpumask_test_cpu(cpu, &p->cpus_allowed) >> > + && !want_energy; >> > } >> > >> > - rcu_read_lock(); >> > for_each_domain(cpu, tmp) { >> > if (!(tmp->flags & SD_LOAD_BALANCE)) >> > break; >> > @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f >> > break; >> > } >> > >> > + /* >> > + * Energy-aware task placement is performed on the highest >> > + * non-overutilized domain spanning over cpu and prev_cpu. >> > + */ >> > + if (want_energy && !sd_overutilized(tmp) && >> > + cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) >> >> Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here for tmp level? > > ... and this then should be covered by the previous check in > wake_energy(), which sets want_energy. Right, but in a scenario which probably doesn't exist today where we have both SD_ASYM_CPUCAPACITY and !SD_ASYM_CPUCAPACITY domains in the hierarchy for which want_energy = 1, I was thinking if its more future proof to check it and not make assumptions... >> >> > + energy_sd = tmp; >> > + >> > if (tmp->flags & sd_flag) >> > sd = tmp; >> > else if (!want_affine) >> > @@ -6586,6 +6652,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f >> > if (want_affine) >> > current->recent_used_cpu = cpu; >> > } >> > + } else if (energy_sd) { >> > + new_cpu = find_energy_efficient_cpu(energy_sd, p, prev_cpu); >> >> Even if want_affine = 0 (want_energy = 1), we can have sd = NULL if >> sd_flag and tmp->flags don't match. In this case we wont enter the EAS >> selection path because sd will be = NULL. So should you be setting sd >> = NULL explicitly if energy_sd != NULL , or rather do the if >> (energy_sd) before doing the if (!sd) ? > > That's the same think I was also proposing in my reply to this patch. > But in my case the point was mainly to make the code easier to > follow... which at the end it's also to void all the consideration on > dependencies you describe above. > > Joel, can you have a look at what I proposed... I was not entirely > sure that we miss some code paths doing it that way. Replied to this in the other thread. thanks, - Joel