Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2100228imj; Sun, 10 Feb 2019 18:43:55 -0800 (PST) X-Google-Smtp-Source: AHgI3IaazJaQeOuQcS0lhSflpMsgHMSZbqUNXu63cc0yt1yL3+dd4EDakDY0ySsI5pKM7FDz3itz X-Received: by 2002:a17:902:8ec9:: with SMTP id x9mr35714672plo.27.1549853035276; Sun, 10 Feb 2019 18:43:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549853035; cv=none; d=google.com; s=arc-20160816; b=naScHZvTNK3SiRLnWNVvk3Aq+zADOygu4orDzlMkav0HNM3enNRp1f/eYlB9yeT0o8 NBfj8PcTix/gEHpST9gvg/P3DiJBLJ/MtCctV4nyQZDmc+OI1Czx5xbPHjpeVsRPOFq9 +QGniQhO67FNm3fDniJ4Zu8gOBiKT1dKL+hY8WkDPiqb+7p+Q/eixeQN08/ZRFZz36y0 pVJtbs1FV0yES2BEtAom7OigklOEENIivlcaZWuaT0gS9vhM8l9xZAmOpCieV1m3FcQp JK/gfJZQ3p+O9srXZ7X25LaT/uMLG52wkc0RS9o/1W8/6mMJ+ry075MuiNE0cfCH6rai vVSw== 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=uvk4+RfUThW91/Hikdw5fop9OXueDda/QF2GEkBilBw=; b=coA1HaCBCtJNLvymCihi0tPuUh3F1D5rcodWG2xyr+USUbu96JWSuxhJwtSw8rUWic cFzAp1pD9KJvw5LwXc5OOKBYfcyopEQzbZuKCB01bpS73I2Juw7VbO+2+YIFH7xtLdOF YYleXgTCaD1xeco21vjqxAsQxC2jlNqrA3Aov1+zvbDH2ddPz0b1OpOzXzxI1FniUcQm mrx4SpotLXIqrKlWhmafa/YD3HYtfOMWsc3h1Pi3BsfugrIQVl+dgS1147CEmax+gejE tj/RVMPqHqk91dgqLVezdNT9emgxXHRoxpRZ3K6cLZYpw+D4NqEFMynKwLa9qMaz/kOm 6hGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rmrN0R2K; 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 u27si1801583pfa.103.2019.02.10.18.43.36; Sun, 10 Feb 2019 18:43:55 -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=rmrN0R2K; 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 S1726366AbfBKCnc (ORCPT + 99 others); Sun, 10 Feb 2019 21:43:32 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:41184 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbfBKCnc (ORCPT ); Sun, 10 Feb 2019 21:43:32 -0500 Received: by mail-lf1-f67.google.com with SMTP id e27so6539755lfj.8 for ; Sun, 10 Feb 2019 18:43:31 -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=uvk4+RfUThW91/Hikdw5fop9OXueDda/QF2GEkBilBw=; b=rmrN0R2KGpZK0TuSxhHpbiq5ZylSrKlERU7QYqjNdDv7gZBTygCuVbc4QI1+snbmfi HVaeljKERmSm6iaLIhw1bu5ofR/aMVLfeineW+UwAldj0m6+oVMaXZqUUlbE3mg+trLQ jF4JRjA79BGLCpVa+qyb+nDlAYd6zFA1PX/xyklZnd5aCME2ues8+xeafKGWYtw9MuxI dJvDZuxCATBO/afZkV3xVCkMuH/fwRCXgMezdCGf1S2zFWqymWb3dqL/HWhSfh8yvWoY m7XnCWJZV+OBArqbRYHIF4yAilTY5MoRh9HRkcDUcbvqqmoXnY5VqBmRA8ak6sgj4EYu dQNQ== 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=uvk4+RfUThW91/Hikdw5fop9OXueDda/QF2GEkBilBw=; b=KlhABvEP6Fq7ce/zZGx51by/w3DSpJcEyyrWGhehSSeo+5Yt4QgRQgL0UpbOqLUD7Z EmbHNRN58JE8CU7+zMzzSD3KKSC7gB8YFi08o6ea90i3P+z26N1lZQ/lNLWCKsQppSca NAgSi/EYjZ73fFcjZS+QdCezS1FK+cZdidVHjSk9C15F7dLKpzODLOfgsmawOlxFFHOG HnY3eG9vkjOG9ZoNsDXcBhtgdlcIk3CiKng2XWJJgxTLM9a71HMDmmjvEdRre9Zn5Vu+ FtbSBlIqTm2fKfJD8WTSvOeKapvXyCtvs+e9TWUnrOCCW1A4mMXT728KDYZX8hfp5zcN kKuw== X-Gm-Message-State: AHQUAuY4P/QHNPE2Gidfz4IFhsfVc0jIW6ro8xYarIV+6HYQ6p1xSFRi DWSIE9h7bMjAjTNohGPEVbrKq+r+eeGeUUmZMzA= X-Received: by 2002:a19:95c1:: with SMTP id x184mr8735994lfd.155.1549853010106; Sun, 10 Feb 2019 18:43:30 -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: <20190206171915.GJ17564@hirez.programming.kicks-ass.net> From: =?UTF-8?B?56a56Iif6ZSu?= Date: Mon, 11 Feb 2019 10:43:18 +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 Hi Peter > The problem I have with this is that it will make schedstats even more expensive :/ I think the overhead for accounting hierarchy wait time is just the same as cpuacct.usage. If the performance overhead is low enough(< 1%), is it acceptable? 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 :/