Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp762080imm; Mon, 2 Jul 2018 22:44:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIdB6B+ygcFAKLM96Amdt7eyri86pbnK02k3akbS4htvVGdeVp/EpnqXFEyxDku/BDcKLqg X-Received: by 2002:a63:8b44:: with SMTP id j65-v6mr24369477pge.248.1530596652144; Mon, 02 Jul 2018 22:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530596652; cv=none; d=google.com; s=arc-20160816; b=XIWfdAqhn6VHE65HfQPxGhhfeW6dAqy9/SL7ZG3FDTeNZbJiYPVptYx5pBFelGiKk5 oT7nqudoWLOtFBmii97aT/OMC7gl9a1peaGfTVXJSdGQ4IjKwPprFhH9qzIy/qgnevx6 o40F2YAEBevVlT7ZSFHSrEe6L0/S1JDpdWoWBSTpQ8A8/elEh7yBetSAF/pVgSeuzrmD ZpF8x58AfWyGUw9EK3iajHAM7Of9hxYZusnlg5OoBBMPAu4oV1y4v8ruQxCeJdboW0X1 YBZxi/gqD2PAGnWNa3Q6IuJPwfzOnHZ28ojR2kJl//Urb3DonGlsRWT8k/vXy3EihHC4 HWpw== 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=vxkJDMtUlxG1YLbtuqDJbx8kSbtbgkCILJHGyE3uGz8=; b=lEKSNprxoQx2g0f2Q4LozJ03mep974hil5DYsLf5nMGTdDEJfHL8jq3+g8H/7KkZHq tZOheaZlewCJweT0/npzoPqEsWlxGzDz8CAI1IYJvhw2L88niMpJ5+tFubFWd9hKLjbE rDfshR8+NAo1CrQvV5iyB9xk5jy5ci9tDdq+IBupGh7eeJjFhTE2e7BfcogEq8Xghjqt 9vECyEGKdOek4Iq7CTTVekMEkFvv0WbCBeCV+0jeBqF+5O37NSZkBk97IbVdPRRq0+ci VZNgdf0oyUrJ5B8Fds8ao4SYDbMDNGHnWEPutpDtXqj0JNV2YRi9gAsHxlRqfHc3Fmtn Etdw== 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 y7-v6si326772pll.37.2018.07.02.22.43.57; Mon, 02 Jul 2018 22:44:12 -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 S1754226AbeGCFmg (ORCPT + 99 others); Tue, 3 Jul 2018 01:42:36 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:40306 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753912AbeGCFmf (ORCPT ); Tue, 3 Jul 2018 01:42:35 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07402;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0T3sNcur_1530596540; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0T3sNcur_1530596540) by smtp.aliyun-inc.com(127.0.0.1); Tue, 03 Jul 2018 13:42:20 +0800 Subject: [PATCH] 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: Date: Tue, 3 Jul 2018 13:42:20 +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: <5c4c978d-e8fb-4bcb-b942-3c6d3dcfc13e@linux.alibaba.com> 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 RFC: redesigned the way to acquire wait_sum kernel/sched/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 78d8fac..cbff06b 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6781,6 +6781,8 @@ static int __cfs_schedulable(struct task_group *tg, u64 period, u64 quota) static int cpu_cfs_stat_show(struct seq_file *sf, void *v) { + int i; + u64 wait_sum = 0; struct task_group *tg = css_tg(seq_css(sf)); struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth; @@ -6788,6 +6790,12 @@ 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()) { + for_each_possible_cpu(i) + wait_sum += tg->se[i]->statistics.wait_sum; + seq_printf(sf, "wait_sum %llu\n", wait_sum); + } + return 0; } #endif /* CONFIG_CFS_BANDWIDTH */ -- 1.8.3.1