Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3062055imj; Mon, 18 Feb 2019 18:51:50 -0800 (PST) X-Google-Smtp-Source: AHgI3IZgdcO7Mi7LFZs7Ymjw5KlMa+AmZpVX7lZEiTj1cznlbJbIfzkAcc5CY0I634+kZvXJ5tkg X-Received: by 2002:a17:902:b784:: with SMTP id e4mr16971949pls.308.1550544710082; Mon, 18 Feb 2019 18:51:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550544710; cv=none; d=google.com; s=arc-20160816; b=cU+dnSWL2tiWLFUt5VR5KKc9g34sR8i0cOEIfLsej4h9jnMqs7J65KF4jWixUZeg0J WS1XEHUNEwPc93cFXNbk2zFzuKd6+jYQPKLzdGenVFO1jLuQd4bn3FvpnS70Qa0T6mGU KdQfumEu0si2xWxkIHJdTlhmMHGIOv8WlGlkM9Rka7PgErqsrFpXCUtEy5NPgF1R7r4N 1pdBy+tK1wUFAz7pF8LsTb+kcoYUbhtDm9zOjGkpAtXEk3o4PyyKFLA1PxSiv2z/b73O 9bWtRv0qzJtmbaas7BnjvwJNQDW2Q7KHejW+5yfUvWzg5uQ+wj2WPhAK3HhyMWDOARDi 1iHg== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=M037U6aipv5HSHtoXlgn20nsrqaH/sUD/ARA/RhtHh8=; b=OP/ePuv2gX7pWzWOv6bL8GVAnMVOKpdiUa8LeR/YFrZcYYFmlv3MMRfxiHIkQ2zNEp 7wI0dHA9+UAvjMWgzEHi+nbiLvUM6cdIzIu2ckP708+8WXRnLKtnjlgkvC1m1/L1gg0h 1hUGj/7y5Gqcn+LFLEFoF4AFQC4mU/o3tnojjSoCEO8IDJz86gghDlE+17DENWJ7GvhT piKTTEW0G/ueZPCP6e3OwWzSaqdnKlrfph967u2niNo6GQAWf3xA1/bOrqEPTvp4unxt Sdpjg6io1bloLABKxOQfqBPyz78hNDUMUprnG9c7IcIznAZ6c40fh8qATu/BxcUo4FYF pHFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RksZb2ib; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q83si14580724pfa.205.2019.02.18.18.51.35; Mon, 18 Feb 2019 18:51:50 -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=@gmail.com header.s=20161025 header.b=RksZb2ib; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727986AbfBSCP2 (ORCPT + 99 others); Mon, 18 Feb 2019 21:15:28 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:33694 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726372AbfBSCP1 (ORCPT ); Mon, 18 Feb 2019 21:15:27 -0500 Received: by mail-lj1-f194.google.com with SMTP id f24-v6so16062046ljk.0 for ; Mon, 18 Feb 2019 18:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M037U6aipv5HSHtoXlgn20nsrqaH/sUD/ARA/RhtHh8=; b=RksZb2ibk50KRaRvwZk35X5nq1c6kM9T5p10Q2Ur+71gkTa/8UHP12DMXqf3atfgpd 5zAvxmbG6nGzFl3hpkF7lVDwr2dTJvlY9v5fprgC1Z68QOVpavf+BYE4RvTyhTgKwyxn KM7Mek8QjlK2XXPhPDhooKqHv/SdNz1usT0eT3Lfie4/vurisjZ0YGJ/PifRJzZGPD/c lK/bWTC4K7hm9p+nEua5B5e3IP4bDv1QbTyAs8Yum/rCXyEqaqbkrmDYcPGgZPQAE13J 2W9LGEr0UyPc8C8vkWhpNo3adLGeCn4Hy1Rfv+AHR3mkH21p14FrRPs7eoyy+0lBbdZb lPRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=M037U6aipv5HSHtoXlgn20nsrqaH/sUD/ARA/RhtHh8=; b=DR7dHS+Y+pmSog6UAveQ5RVwFcEm6N4Lr5iqoriEysJHgGQRTJ5WCKOGnY8IAim7mS LhgZ4jz882UJ0YlrYk+2tri/a1APoIICphKlwKxBaPIjWu7TgWcli2dmfqZZ1W+ojNhU eK6poym053crmcwjLdGZyYaHe8K+4rt6MoZ23NoEkNxbCl6M+aPryn9CqW9S5OhCbGzv 2RCG8+zL/rHTUxqXiNgEaCBd0nEJdBH6NhbFz6eOW3kjloYGOXJBraAq2lkwHydWZdrF ADSTp+fpuxOYPI+NIXpqBghb61bEQlr037ewSqFJ4PaaJZw8rZNT/uqYZdpTgLN+7lOW W8/w== X-Gm-Message-State: AHQUAuaMOkhYH+F8rvMPnIlzAR03FM2Z4rTE74ZT18uX5Kj2cfwdCWEq jpStsbPWfCasSIpR0jMfOt5CjRG76XrDYRJKhhQ= X-Received: by 2002:a2e:91d4:: with SMTP id u20mr6156203ljg.54.1550542525612; Mon, 18 Feb 2019 18:15:25 -0800 (PST) MIME-Version: 1.0 References: <1548236816-18712-1-git-send-email-ufo19890607@gmail.com> <20190206171915.GJ17564@hirez.programming.kicks-ass.net> In-Reply-To: From: =?UTF-8?B?56a56Iif6ZSu?= Date: Tue, 19 Feb 2019 10:15:14 +0800 Message-ID: Subject: Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group To: Peter Zijlstra Cc: mingo@redhat.com, =?UTF-8?B?546L6LSH?= , Wind Yu , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org PING =E7=A6=B9=E8=88=9F=E9=94=AE =E4=BA=8E2019=E5=B9=B42= =E6=9C=8812=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=8811:14=E5=86=99=E9= =81=93=EF=BC=9A > > Hi, Peter > I think hierarchy wait time for task groups is worth accounting > despite with a little extra overhead. Because we can evaluate task > groups' condition with a more direct metric. We cannot get the real > situation just with some general metrics, like idle or loadavg, since > their value is decreased with the elapse of time. So, I think general > metrics cannot satisify the request for task groups. > > Thanks > Yuzhoujian > > > Peter Zijlstra =E4=BA=8E2019=E5=B9=B42=E6=9C=887= =E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=881:19=E5=86=99=E9=81=93=EF=BC= =9A > > > > On Wed, Jan 23, 2019 at 05:46:56PM +0800, ufo19890607@gmail.com wrote: > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index e2ff4b6..35e89ca 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -858,6 +858,19 @@ static void update_curr_fair(struct rq *rq) > > > } > > > > > > static inline void > > > +update_hierarchy_wait_sum(struct sched_entity *se, > > > + u64 delta_wait) > > > +{ > > > + for_each_sched_entity(se) { > > > + struct cfs_rq *cfs_rq =3D cfs_rq_of(se); > > > + > > > + if (cfs_rq->tg !=3D &root_task_group) > > > + __schedstat_add(cfs_rq->hierarchy_wait_sum, > > > + delta_wait); > > > + } > > > +} > > > + > > > +static inline void > > > update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se= ) > > > { > > > struct task_struct *p; > > > @@ -880,6 +893,7 @@ static void update_curr_fair(struct rq *rq) > > > return; > > > } > > > trace_sched_stat_wait(p, delta); > > > + update_hierarchy_wait_sum(se, delta); > > > } > > > > > > __schedstat_set(se->statistics.wait_max, > > > > The problem I have with this is that it will make schedstats even more > > expensive :/