Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2335010imm; Fri, 7 Sep 2018 14:53:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZy/OK/RRWqaoJEp+qHEoGpAnFngC/oNORpR2tlcnotOp6PTwOovAwjKboW/UJfPyIkgyJR X-Received: by 2002:a17:902:7287:: with SMTP id d7-v6mr10275683pll.54.1536357209638; Fri, 07 Sep 2018 14:53:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536357209; cv=none; d=google.com; s=arc-20160816; b=nyhtJigLmHMY5BUV987DlwBqVHEgne4+fWTj7SaVo/esKx6izMKlMT4sNDkBOoQU46 Q2kYkYc0Kep6wGyMFuxrAGsZGX7OdOIrcRCZYnGS6RdcSK713r0BpvbZTR+OaOSmCqSq NO+XMRDyOb+WtdDIT2lKliR3GoX38/hfsRSUT3EwgKBqzC+TrH7f4/ITSVAn3FCpc0ga jL+dqVSxxWzv3GZI6ZXlv9OSNIIKSpwgWlEXHzum5dRn2WVPlIubdoQx2mdszvNT4YZV 83MDjpcsoVXp85UYcGHApbO9AmHS1tWo4CbUskDZe/9MFJOqG4bIj7umbAIW3BVWQSVK qQeA== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=iEzeSY3HXZePtDrTXPKWmRO6bwBvGIC8DYKkivdhMJc=; b=aSAUHtVmXAwOTQ4GtNvaoUkF1vQ7jSP6IukdrRzXqoIbiZ6dIounJ53/w/6Mk7iswY 4ZxJJm4dyJy1bcPJqSeUaYdbMUiBL05rYxz1iR0TeUalL4s7sEgOe3ng0oYoIDHLR3Wp hQBlbnQgzH4E2O1Vb7//cVgyoj25BixXrxLgHk7oPM0nGxabIOqi1ekrjQcTp7GQmDCV 4L7z8MWT8015HbhoAgm4HWG6RRZH87v4gTbOfRdHuEHsX6wiuNpmJw+SzHFnDpQVnCaP gaESaO4dtxXU9Xv9I3rSiF1MoRlcq/e8Q+uO5q/Hm9JeBhKTiH3Dqzy3G55o9RU3iDeL ydzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=AQhjO7xY; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p17-v6si4645837plo.363.2018.09.07.14.53.14; Fri, 07 Sep 2018 14:53:29 -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=@amazon.de header.s=amazon201209 header.b=AQhjO7xY; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730128AbeIHCZp (ORCPT + 99 others); Fri, 7 Sep 2018 22:25:45 -0400 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]:55298 "EHLO smtp-fw-4101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730289AbeIHCZo (ORCPT ); Fri, 7 Sep 2018 22:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1536356569; x=1567892569; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=iEzeSY3HXZePtDrTXPKWmRO6bwBvGIC8DYKkivdhMJc=; b=AQhjO7xYzMc2BoEwcfC8X//cdzpU3fvbn5Peabwjc37viSrguaqFJmgJ ZZGxVuKz8f3L55nc1NYx+rW6CwSBkrw8/qABnDLJ48YVj5gK91Q8IeciM zwqgnADiLtFXgMGLc2uI0FZcxUK8+emHs/dGHgV1anbTmauZqPvHGRqm4 4=; X-IronPort-AV: E=Sophos;i="5.53,343,1531785600"; d="scan'208";a="737530499" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2018 21:42:49 +0000 Received: from u7588a65da6b65f.ant.amazon.com (iad7-ws-svc-lb50-vlan2.amazon.com [10.0.93.210]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w87Lggh7013102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Sep 2018 21:42:45 GMT Received: from u7588a65da6b65f.ant.amazon.com (localhost [127.0.0.1]) by u7588a65da6b65f.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTPS id w87Lgf2C027687 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Sep 2018 23:42:41 +0200 Received: (from jschoenh@localhost) by u7588a65da6b65f.ant.amazon.com (8.15.2/8.15.2/Submit) id w87Lgeqh027680; Fri, 7 Sep 2018 23:42:40 +0200 From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= To: Ingo Molnar , Peter Zijlstra Cc: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= , linux-kernel@vger.kernel.org Subject: [RFC 45/60] cosched: Continue to account all load on per-CPU runqueues Date: Fri, 7 Sep 2018 23:40:32 +0200 Message-Id: <20180907214047.26914-46-jschoenh@amazon.de> X-Mailer: git-send-email 2.9.3.1.gcba166c.dirty In-Reply-To: <20180907214047.26914-1-jschoenh@amazon.de> References: <20180907214047.26914-1-jschoenh@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Even with coscheduling, we define the fields rq->nr_running and rq->load of per-CPU runqueues to represent the total amount of tasks and the total amount of load on that CPU, respectively, so that existing code continues to work as expected. Make sure to still account load changes on per-CPU runqueues. The change in set_next_entity() just silences a warning. The code looks bogus even without coscheduling, as the weight of an SE is independent from the weight of the runqueue, when task groups are involved. It's just for statistics anyway. Signed-off-by: Jan H. Schönherr --- kernel/sched/fair.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index fff88694560c..0bba924b40ba 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2741,8 +2741,8 @@ static void account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se) { update_load_add(&cfs_rq->load, se->load.weight); - if (!parent_entity(se)) - update_load_add(&rq_of(cfs_rq)->load, se->load.weight); + if (!parent_entity(se) || is_sd_se(parent_entity(se))) + update_load_add(&hrq_of(cfs_rq)->load, se->load.weight); #ifdef CONFIG_SMP if (entity_is_task(se)) { struct rq *rq = rq_of(cfs_rq); @@ -2758,8 +2758,8 @@ static void account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se) { update_load_sub(&cfs_rq->load, se->load.weight); - if (!parent_entity(se)) - update_load_sub(&rq_of(cfs_rq)->load, se->load.weight); + if (!parent_entity(se) || is_sd_se(parent_entity(se))) + update_load_sub(&hrq_of(cfs_rq)->load, se->load.weight); #ifdef CONFIG_SMP if (entity_is_task(se)) { account_numa_dequeue(rq_of(cfs_rq), task_of(se)); @@ -4122,7 +4122,8 @@ set_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *se) * least twice that of our own weight (i.e. dont track it * when there are only lesser-weight tasks around): */ - if (schedstat_enabled() && rq_of(cfs_rq)->load.weight >= 2*se->load.weight) { + if (schedstat_enabled() && + hrq_of(cfs_rq)->load.weight >= 2 * se->load.weight) { schedstat_set(se->statistics.slice_max, max((u64)schedstat_val(se->statistics.slice_max), se->sum_exec_runtime - se->prev_sum_exec_runtime)); -- 2.9.3.1.gcba166c.dirty