Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3860610ybi; Fri, 19 Jul 2019 10:17:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqyqos9+b6zDjmBj32Tg6ogzM6hXAdYLwpL/tjpv0QJN3RG47pH83WzVZbDqYAWpz3HFzIge X-Received: by 2002:a17:90a:cb8e:: with SMTP id a14mr10568320pju.124.1563556627776; Fri, 19 Jul 2019 10:17:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563556627; cv=none; d=google.com; s=arc-20160816; b=Hw7bkYyJ41vpnaWkhBBu4VR2oeE16LsS2WseYAMADffyNbw+VQlfMfWe1WbrUxBcyt U37BhN9KEcgk5mwvDD56dqnYbQDEL07zxP1+q7gXJzI335sBwxm4AoT966LJcWCXCYqI U1s5NqW3A7Tlsvukn0s/VkfYFw3suYSFslJUStbt9ZQ9sFMxNi4mUvhqhayWURPRw1bs EhdX6o4XQmh/9PqCyeVRU9iEQaQ4Uj6/6Uu/PyjiAUIKeQ2ktUqY9WOxmjJKERxBPByK h+8PVZD2CrBO6Vm7r/gfOim8Mz4v9ErdRVSbjj14COjo37j5k7gvzt5wb9l/1Q6efLge pLAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=5EaHXGuJMjh+887xI3sY026uNAnaO8i0Ga0Wfac/FRc=; b=VEQYH0zADmFMie+p7G9tP/Q4akH+jXs5AwJu8Pm6gAMtUokha2/V430HLwLnRYv5PU kDTY7MqXk+gKQDDjW8Zt0k3267QV9k3HyRy8lEImr+EWByoJ+uqbjavnO7X1x/7GQtix CgXRleqG8p1Vpr+nAjzT9uAXzSYLofMEqaOv3jjxRh8PsynusfV57uH/w68lLy+d+S1H L/gUjP5AEG8FOhpbGCxRAnGXDUXX0T08KY4waEVKnUXhmL/7RGuXa9bBxJc1/D8z5l4Y SQ1zeBPShdVG/+Can2VT5WYBde9LbYc67pSBx4Neh+XI/G1Efih6kCP44damBtZzOLmZ WSMg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61si1593329ple.275.2019.07.19.10.16.51; Fri, 19 Jul 2019 10:17:07 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731186AbfGSQjj (ORCPT + 99 others); Fri, 19 Jul 2019 12:39:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:41974 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727577AbfGSQjj (ORCPT ); Fri, 19 Jul 2019 12:39:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8D338AF9C; Fri, 19 Jul 2019 16:39:37 +0000 (UTC) Date: Fri, 19 Jul 2019 18:39:31 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: =?utf-8?B?546L6LSH?= Cc: hannes@cmpxchg.org, vdavydov.dev@gmail.com, Peter Zijlstra , mhocko@kernel.org, Ingo Molnar , keescook@chromium.org, mcgrof@kernel.org, linux-mm@kvack.org, Hillf Danton , cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/4] numa: append per-node execution time in cpu.numa_stat Message-ID: <20190719163930.GA854@blackbody.suse.cz> References: <209d247e-c1b2-3235-2722-dd7c1f896483@linux.alibaba.com> <60b59306-5e36-e587-9145-e90657daec41@linux.alibaba.com> <65c1987f-bcce-2165-8c30-cf8cf3454591@linux.alibaba.com> <6973a1bf-88f2-b54e-726d-8b7d95d80197@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6973a1bf-88f2-b54e-726d-8b7d95d80197@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 16, 2019 at 11:40:35AM +0800, 王贇 wrote: > By doing 'cat /sys/fs/cgroup/cpu/CGROUP_PATH/cpu.numa_stat', we see new > output line heading with 'exectime', like: > > exectime 311900 407166 What you present are times aggregated over CPUs in the NUMA nodes, this seems a bit lossy interface. Despite you the aggregated information is sufficient for your monitoring, I think it's worth providing the information with the original granularity. Note that cpuacct v1 controller used to report such percpu runtime stats. The v2 implementation would rather build upon the rstat API. Michal