Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp668068pxb; Fri, 14 Jan 2022 13:35:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJzvUxGsnOVCwjgXsT/FN52vrATUqt7JqbD6eNKyyIRvsgICe3LbytzrR2GcA4pJa6cjQ7+V X-Received: by 2002:a05:6a00:810:b0:4c1:e21d:a900 with SMTP id m16-20020a056a00081000b004c1e21da900mr10207447pfk.6.1642196154357; Fri, 14 Jan 2022 13:35:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642196154; cv=none; d=google.com; s=arc-20160816; b=l4tCmqWuYXGQ82BBNIpBdTNfL1ee+xdtM7R0Z70f4RTqgEWBcG2dRuigS0KEshAMvS EV9BcGHyop8QAwwlTXpebiTeuSkdcwAXjQqE94Lofm7giAFHisV47aiWcNhS3LCrLFw0 9P53fxCr5H6Kvuk9yWZFRy9SZrLs1D6ekJvZTQPEqXE867o5wD78pePm/NEf8rocGzGB uVBdFT2jO3BkLFjQ1wq4G5C3evlogJd5CQ03QuJnCCK04SeC58oKieMV8GlPx7uI0iaK Ptt8qlmjvSMHtDvezt3UYE+H9Xd2RgOPaE3DP+wDMeOPnTYGbjG9mtJAzotqpnExtTF9 PqJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=eR/cq8BHHJTtw5GrdXci273DWPZhmP8NEYjv6hovt3o=; b=UpxkJ0B/7pU/fIU15Dkl3PD5HkJDptbJG4Fc33hbhnmO7gFpcIUctvTYKGGLe9p1f0 5OFVwbvDEVapPZbLXsLjcFnBenWvlcJKlz8EZxeH8ijabFoQcjcqlcFQy20OZ6jpoh1n qX8niQs2vjYJoIMScpk2q3SAEVYT0wL4JKuJlrdFp/CTLw/kUHpQxoVuhKyszFQqINO9 mgwFn4Btm9dJn/hMXjFNiiiDb+aFUkepGTTQqm/IbrbCW3dZoo5zbqvQx234mmgzyvAa vD9i5QSI4bzayysWV9vABwcb03NZhiPJWm9onIa3M99MUDrIih33vlL85z3insCfC1Rc miCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id l11si3743073pls.142.2022.01.14.13.35.42; Fri, 14 Jan 2022 13:35:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S241900AbiANPES (ORCPT + 99 others); Fri, 14 Jan 2022 10:04:18 -0500 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:34282 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238270AbiANPEQ (ORCPT ); Fri, 14 Jan 2022 10:04:16 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R871e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04357;MF=cruzzhao@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0V1pfdAE_1642172651; Received: from 30.21.164.113(mailfrom:cruzzhao@linux.alibaba.com fp:SMTPD_---0V1pfdAE_1642172651) by smtp.aliyun-inc.com(127.0.0.1); Fri, 14 Jan 2022 23:04:12 +0800 Message-ID: <86fbc313-e179-0cbd-8f5b-66e7b5964b14@linux.alibaba.com> Date: Fri, 14 Jan 2022 23:04:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH v2 2/3] sched/core: Forced idle accounting per-cpu Content-Language: en-US To: Josh Don Cc: Tejun Heo , Zefan Li , Johannes Weiner , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , cgroups@vger.kernel.org, linux-kernel References: <1641894961-9241-1-git-send-email-CruzZhao@linux.alibaba.com> <1641894961-9241-3-git-send-email-CruzZhao@linux.alibaba.com> From: cruzzhao In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/1/12 上午9:59, Josh Don 写道: > On Tue, Jan 11, 2022 at 1:56 AM Cruz Zhao wrote: >> >> Accounting for "forced idle" time per cpu, which is the time a cpu is >> forced to idle by its SMT sibling. >> >> As it's not accurate to measure the capacity loss only by cookie'd forced >> idle time, and it's hard to trace the forced idle time caused by all the >> uncookie'd tasks, we account the forced idle time from the perspective of >> the cpu. >> >> Forced idle time per cpu is displayed via /proc/schedstat, we can get the >> forced idle time of cpu x from the 10th column of the row for cpu x. The >> unit is ns. It also requires that schedstats is enabled. >> >> Signed-off-by: Cruz Zhao >> --- > > Two quick followup questions: > > 1) From your v1, I still wasn't quite sure if the per-cpu time was > useful or not for you versus a single overall sum (ie. I think other > metrics could be more useful for analyzing steal_cookie if that's what > you're specifically interested in). Do you definitely want the per-cpu > totals? > IMO, the per-cpu forced idle time can help us get to know whether the forced idle time is uniform among the core, or among all the cpus. IMO, it's a kind of balance. > 2) If your cgroup accounting patch is merged, do you still want this > patch? You can grab the global values from the root cgroup (assuming > you have cgroups enabled). The only potential gap is if you need > per-cpu totals, though I'm working to add percpu stats to cgroup-v2: > https://lkml.kernel.org/r/%3C20220107234138.1765668-1-joshdon@google.com%3E If cgroup accounting patch is merged, this patch is still needed. Consider the following scenario: Task p of cgroup A is running on cpu x, and it forces cpu y into idle for t ns. The forceidle time of cgroup A on cpu x increases t ns, and the forcedidle time of cpu y increases t ns. That is, the force idle time of cgroup is defined as the forced idle time it caused, and the force idle time of cpu is defined as the time the cpu is forced into idle, which have different meanings from each other. And for SMT > 2, we cannot caculate the forced idle time of cpu x from the cgroup interface. Best, Cruz Zhao