Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5811823imm; Mon, 23 Jul 2018 06:33:31 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfTP6x168CQ0RjpsR658q0U84Hv4gDpoYWKTcS3AEvvVZo1GuPcgFm5E8dFDOmNBSze2ysf X-Received: by 2002:a62:2459:: with SMTP id r86-v6mr8146988pfj.31.1532352811628; Mon, 23 Jul 2018 06:33:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532352811; cv=none; d=google.com; s=arc-20160816; b=sBZK97jIs8SLcvBukcNuMbJPYM7DP6QRQBq764DyhdK0aFdbi3g9hU6zAZ2N3wRb+L eCM9v2grPSJaTc8tjPtwpBy2Cb/mk8lgUnFZB5w0mjPT/npFmEmVS0wGvhUYSwwrFqny dSAe0TbKtIHgUxLwxyEJ0YMRuV0lMoL1LU5DG8BXVrYWDzGNRKmKCfZzAvfm3SBiCzea vVBw46WP9Xx3Ryudk2zT2aWdHZG9iUi+8NtmeneMcT+OKrAxf70odl5mA05nxhfWIPqJ wo4JeO85RSQSy05aTBmzj9lTQaD1593UqVDFv6McKb1me+k43Qn7FBUSPUfINm29ra80 +mAw== 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:references:to:from:subject:arc-authentication-results; bh=NzxV5eMViz+yXjKxASDxe6o4B8TwtOiAuETsqgMrk6U=; b=Ic84+sUlgTTj69RMbTVPVcqG2zqoLRqKdwXGCP2zRENJBi4mA+xdE4U+nU+QKNdJbE Gm35hbM7Sn9mHYr/Qc94oj1cJGN0PQKiwyks0ZZFyEfFZgu0B02Q1t29tTr4Ar8Ylcj/ nTVJhlV0rcfvG6oMJC1PQs67Ywj+wuHQNNBNeA8rIcfDhtGUKqmdS9gzeu8D3jpNKu2U 9bheaVO3XdOIYfnjzSd4CdeoYEbH2vqgoCkmMudSqYCwbdIoIQ/bH/XKTsW9ZBPbM/+4 Cx65Jp6yT3tSaPmbSu3lhN2bSUkf36IrEB51v5Pxyr4gEtuEcu2Mktbhdi4qKfBqImeU DaYQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si8432393pld.84.2018.07.23.06.33.17; Mon, 23 Jul 2018 06:33:31 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388204AbeGWOdE (ORCPT + 99 others); Mon, 23 Jul 2018 10:33:04 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:36443 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388083AbeGWOdE (ORCPT ); Mon, 23 Jul 2018 10:33:04 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R721e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04452;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0T5AWNMp_1532352703; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0T5AWNMp_1532352703) by smtp.aliyun-inc.com(127.0.0.1); Mon, 23 Jul 2018 21:31:44 +0800 Subject: [PATCH v3] tg: show the sum wait time of an task group From: =?UTF-8?B?546L6LSH?= To: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org References: <5c4c978d-e8fb-4bcb-b942-3c6d3dcfc13e@linux.alibaba.com> Message-ID: <336c292e-be0a-f03d-d992-9f55b969ed12@linux.alibaba.com> Date: Mon, 23 Jul 2018 21:31:26 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.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 Although we can rely on cpuacct to present the cpu usage of task group, it is hard to tell how intense the competition is between these groups on cpu resources. Monitoring the wait time of each process or sched_debug could cost too much, and there is no good way to accurately represent the conflict with these info, we need the wait time on group dimension. Thus we introduced group's wait_sum represent the conflict between task groups, which is simply sum the wait time of group's cfs_rq. The 'cpu.stat' is modified to show the statistic, like: nr_periods 0 nr_throttled 0 throttled_time 0 wait_sum 2035098795584 Now we can monitor the changing on wait_sum to tell how suffering a task group is in the fight of cpu resources. For example: (wait_sum - last_wait_sum) * 100 / (nr_cpu * period_ns) == X% means the task group paid X percentage of period on waiting for the cpu. Signed-off-by: Michael Wang --- Since v2: Declare variables inside branch (From Peter). kernel/sched/core.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 78d8fac..2a7bb7c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6788,6 +6788,15 @@ static int cpu_cfs_stat_show(struct seq_file *sf, void *v) seq_printf(sf, "nr_throttled %d\n", cfs_b->nr_throttled); seq_printf(sf, "throttled_time %llu\n", cfs_b->throttled_time); + if (schedstat_enabled() && tg != &root_task_group) { + int i; + u64 ws = 0; + + for_each_possible_cpu(i) + ws += schedstat_val(tg->se[i]->statistics.wait_sum); + seq_printf(sf, "wait_sum %llu\n", ws); + } + return 0; } #endif /* CONFIG_CFS_BANDWIDTH */ -- 1.8.3.1