Received: by 10.223.176.5 with SMTP id f5csp1911596wra; Thu, 8 Feb 2018 05:37:56 -0800 (PST) X-Google-Smtp-Source: AH8x224drVbr6OrsWbSDzCZNjHPF9aHI6aGd/zQy3B2C9wwk0VnAhcawhw4V1FLwwsGORzjooZ4q X-Received: by 2002:a17:902:b43:: with SMTP id 61-v6mr679292plq.127.1518097076400; Thu, 08 Feb 2018 05:37:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518097076; cv=none; d=google.com; s=arc-20160816; b=figj3evNP+E0hUpX55pyoosfQDkKoD59PggE1wEEDfMVwWxX+CYwINjEseuEoiwPbA 3GhYOgcsbLOR1GSCZr1bmHOAnRNNhg7XiWf+Ed5CoEU0+yAkzHqiln6Up5GERUeA9cK1 BemY2t2Zqf8w09dmKxRXdkDqIsmQw0rjihJIpXM4TJ9Yi4KX0ZUXY4OxNU7XTYRnE8m5 s9DDBAiXlR5rYXPCpUu1duqtHrvRmgmx6y2qe4cNWvVRlso4SLBasNnT3TI+SBZYC08J rhtg4/hsyKPSM4HSSzUzQ0INiMQGM/LO+4J+gI6cuM2nSWUvZeVhNCdYNwJ3DI0HtfBX NC/A== 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=jq67j65LmQCdfDs+JZXLLL9Toxu2ENsUq62vCfx8i/U=; b=nYBhyB/mRblhaYdQIUCYzkReq8vVTaQO20T5gSle91eqff4eiKL1NXEoROv6otqZNr zTxcOsrqUqYa1VUocpS668A97EKcJTyWyEmdytLd9Yg76N1UrA97BP0i6/ZY5i70gI2P L7yPpPz67Eo3MLBaLuwe1N+DR486sUfFb0sILB/MyLTJ4omn59eNc70+GGZEhhGq1+LQ PUFqMR+ey89/NFlk7xJ3X2BZWgh9sfokBD6dJI82eeFCZ2VxTAVfO0EN9nXQlA+kAcqe lVwo7AIJCMDCJmJmMCLq/VWlEaJujaGae2x8ucqI7yBUAzCzdPSIFejLlXRefgdb/HmD lDcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=S0O+zEhO; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o17si1097413pge.371.2018.02.08.05.37.42; Thu, 08 Feb 2018 05:37:56 -0800 (PST) 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=@linaro.org header.s=google header.b=S0O+zEhO; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbeBHNhC (ORCPT + 99 others); Thu, 8 Feb 2018 08:37:02 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:37773 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750961AbeBHNhB (ORCPT ); Thu, 8 Feb 2018 08:37:01 -0500 Received: by mail-io0-f196.google.com with SMTP id f89so5782192ioj.4 for ; Thu, 08 Feb 2018 05:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jq67j65LmQCdfDs+JZXLLL9Toxu2ENsUq62vCfx8i/U=; b=S0O+zEhOcg2L/otOvUrsyXA957HBMpbZAYQ9rEC1Kwt4qwZgHu0OaSY7f4ffAqYNeG ceCA2+txreugJSGc6wehjEjyOpC57uqBFy06em48eQ8BoTdOk7mTqHU2+toYiGdxBCa1 eY0KhM0zxn14W0Xke7PAF1MoAk7qYiEUZs0Tc= 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=jq67j65LmQCdfDs+JZXLLL9Toxu2ENsUq62vCfx8i/U=; b=EC+RxqX3NGRY9GbFuF81rfsNk7+qWJwSouGhEOPIkbGh48d3fCYH7lwHHPFogai0Mw DhHrwb4Fd6of74j2j/VPl64+ioKN7k4XDceIdtQrKeoZ82lwGwfdltGUH0VwdBmLhsk+ NC+ztoxLXDbGR268depPIfRS+DiRW1Mk8GUATTyGQNoWCOvDvXeqdh4GcV1cBK36PKRg +PLUbQmLcbhLY473K87z/u+KV3GUwb8hPhUgs3Ukve7EmD57/GgAiuru5S5G6bUjYx7Q Ymk9IuyVtVi28dRkqjQzud+QqRXpIhZstKIgZuMsWQFB6LO9Ovt4rh8dQWcuF3DsuG9J PBhg== X-Gm-Message-State: APf1xPCkUI6MhZaoyazeGA9JimrtPwblZ+I1JtYVoZVROlrj7Gy0z4Wy IK3c00Gphf3OaSxIzscCNkVHbRHsiINyI6hS/w+T+w== X-Received: by 10.107.53.22 with SMTP id c22mr807196ioa.189.1518097020776; Thu, 08 Feb 2018 05:37:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Thu, 8 Feb 2018 05:36:40 -0800 (PST) In-Reply-To: <780a5b3a-4829-4195-c8fd-95da27248a82@arm.com> References: <1517944987-343-1-git-send-email-vincent.guittot@linaro.org> <1517944987-343-2-git-send-email-vincent.guittot@linaro.org> <780a5b3a-4829-4195-c8fd-95da27248a82@arm.com> From: Vincent Guittot Date: Thu, 8 Feb 2018 14:36:40 +0100 Message-ID: Subject: Re: [PATCH v2 1/3] sched: Stop nohz stats when decayed To: Valentin Schneider Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Morten Rasmussen , Brendan Jackman , Dietmar Eggemann 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 8 February 2018 at 13:46, Valentin Schneider wrote: > On 02/06/2018 07:23 PM, Vincent Guittot wrote: >> [...] >> @@ -7826,8 +7842,8 @@ static inline void update_sg_lb_stats(struct lb_env *env, >> for_each_cpu_and(i, sched_group_span(group), env->cpus) { >> struct rq *rq = cpu_rq(i); >> >> - if (env->flags & LBF_NOHZ_STATS) >> - update_nohz_stats(rq); >> + if ((env->flags & LBF_NOHZ_STATS) && update_nohz_stats(rq)) >> + env->flags |= LBF_NOHZ_AGAIN; >> >> /* Bias balancing toward cpus of our domain */ >> if (local_group) >> @@ -7979,18 +7995,15 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd >> struct sg_lb_stats *local = &sds->local_stat; >> struct sg_lb_stats tmp_sgs; >> int load_idx, prefer_sibling = 0; >> + int has_blocked = READ_ONCE(nohz.has_blocked); >> bool overload = false; >> >> if (child && child->flags & SD_PREFER_SIBLING) >> prefer_sibling = 1; >> >> #ifdef CONFIG_NO_HZ_COMMON >> - if (env->idle == CPU_NEWLY_IDLE) { >> + if (env->idle == CPU_NEWLY_IDLE && has_blocked) >> env->flags |= LBF_NOHZ_STATS; >> - >> - if (cpumask_subset(nohz.idle_cpus_mask, sched_domain_span(env->sd))) >> - nohz.next_stats = jiffies + msecs_to_jiffies(LOAD_AVG_PERIOD); >> - } >> #endif >> >> load_idx = get_sd_load_idx(env->sd, env->idle); >> @@ -8046,6 +8059,15 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd >> sg = sg->next; >> } while (sg != env->sd->groups); >> >> +#ifdef CONFIG_NO_HZ_COMMON >> + if ((env->flags & LBF_NOHZ_AGAIN) && >> + cpumask_subset(nohz.idle_cpus_mask, sched_domain_span(env->sd))) { >> + >> + WRITE_ONCE(nohz.next_blocked, >> + jiffies + msecs_to_jiffies(LOAD_AVG_PERIOD)); > > Here we push the stats update forward if we visited all the nohz CPUs but they > still have blocked load. IMO we should also clear the nohz.has_blocked flag > if we visited all the nohz CPUs and none had blocked load left. > > If we don't do that, we could very well have cleared all of the nohz blocked > load in idle_balance and successfully pulled a task, but the flag isn't > cleared so we'll end up doing a _nohz_idle_balance() later on for nothing. > > > As I said in a previous comment, we also have this problem with periodic > load balance: if a CPU goes nohz (nohz.has_blocked is raised) but wakes up, > e.g. before the next nohz.next_blocked, we should stop kicking ILBs > > Now I'd need to test this, but I think it can actually get worse: if that > CPU keeps generating blocked load after this short idle period, no matter > how many _nohz_idle_balance() we go through we will never reach a point > where nohz.has_blocked gets cleared, and we'll keep kicking those ILBs to > update blocked load that already gets updated in the periodic balance. > > I think that's where a nohz blocked load cpumask can also help: on top of > skipping nohz CPUs that don't need an update, we can stop the whole remote > update machinery when the last nohz cpu with blocked load wakes up, or say > when it goes through its first periodic balance. The main question is : Do we want to remove all useless kicks to ilb or useless calls to _nohz_idle_balance at the cost of adding more latency in the idle/wakeup path because of the additional atomic operations to keep track of which CPUs are idle, tickless with blocked load or do we accept to kick ilb or call _nohz_idle_balance uselessly from time to time for some use cases I agree with you that there are some useless calls with the proposal which can be removed with additional checks, variables and cpumask manipulation. Which use case will benefits from these additional checks and does it worth ? Vincent > >> + } >> +#endif >> + >