Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp331720imm; Tue, 3 Jul 2018 20:29:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeG+uK06x13TVfO4RVhcgkE3c/Yq9lgijWk3Ely04bZtLVlKBZH5th0E7ekBZ9xWeE1olfl X-Received: by 2002:a63:7454:: with SMTP id e20-v6mr334173pgn.410.1530674963813; Tue, 03 Jul 2018 20:29:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530674963; cv=none; d=google.com; s=arc-20160816; b=M7qHU3ScW2uzLwh5R77SMwidcDKe4X4T4LKNHR8vdxxKrjt4t2C6f4mkX5u3oWBoDk lsRKr+Is+qOac3nWmatUs/OX7gScTix5mATCyITary2ThNl6VtLMrZqlrSZ0xmR8uI/+ HKS9ayaKi1HvEKAkDfoL9iI7+JUjT61SnrBXvNYukZqPwzLt6QUHixOMje9NP+d4lK/i Fsi/X5doiTRRIwCAv6QLyGbcYUSqaviQaXfr1w1nTGnvH6sq/8oZJtY8LQcXftqDSp7T 2BF7zXOgoVPWoCkzfzUCZs3ojsl4K8EUFy/FwzYacZ0MNUWWGB9c6YJWmSS3gk/BSJ40 w/eQ== 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=o/amOS/gbR2pTImROhutU7z9jJTQjOrwAkBBwkpJMUA=; b=ySlLTpb8q0qJAkF3FE7/uhixowi3j1U7SpEKIuH1pIro4SO7g+ftl4xexDGwjDa+Pu 8SXcRRY7eaVPvZqymmDexXy3cyEIS874fcTFz2nO4ehR/d6oMiGKXOkYtFTGZKfVELxK xnmBJfl0UgHmui6DEmjIQnqb4acvJwDDRL+IxN+4WuaZzOt2BoMRvaZfCSph9oI7uJFw v48m/w/51reucxzISGAm6V/sbzQ/5TtdpuX0I2aPOpMfM48o53J6o/6Kjzw9HGl3z43G ok1PVskDQPt5caZ28xYUdRcdY7SkOPDrs6qn9utdvPHaHEk3oZ4EbZZELgvw1ZBVP9JJ zdyQ== 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 v203-v6si2256777pgb.333.2018.07.03.20.28.58; Tue, 03 Jul 2018 20:29:23 -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 S932992AbeGDD1m (ORCPT + 99 others); Tue, 3 Jul 2018 23:27:42 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:35264 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932471AbeGDD1l (ORCPT ); Tue, 3 Jul 2018 23:27:41 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R481e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01353;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0T3x2Ovw_1530674847; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0T3x2Ovw_1530674847) by smtp.aliyun-inc.com(127.0.0.1); Wed, 04 Jul 2018 11:27:27 +0800 Subject: [PATCH v2] 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: Wed, 4 Jul 2018 11:27:27 +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 v1: Use schedstat_val to avoid compile error Check and skip root_task_group kernel/sched/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 78d8fac..80ab995 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 ws = 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() && tg != &root_task_group) { + 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