From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E630C432C0 for ; Fri, 29 Nov 2019 05:19:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A13021736 for ; Fri, 29 Nov 2019 05:19:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726811AbfK2FTm (ORCPT ); Fri, 29 Nov 2019 00:19:42 -0500 Received: from out30-44.freemail.mail.aliyun.com ([115.124.30.44]:35519 "EHLO out30-44.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725812AbfK2FTm (ORCPT ); Fri, 29 Nov 2019 00:19:42 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04395;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0TjMcOpq_1575004773; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0TjMcOpq_1575004773) by smtp.aliyun-inc.com(127.0.0.1); Fri, 29 Nov 2019 13:19:34 +0800 Subject: Re: [PATCH v2 1/3] sched/numa: advanced per-cgroup numa statistic From: =?UTF-8?B?546L6LSH?= To: =?UTF-8?Q?Michal_Koutn=c3=bd?= Cc: Mel Gorman , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Luis Chamberlain , Kees Cook , Iurii Zaikin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, "Paul E. McKenney" References: <743eecad-9556-a241-546b-c8a66339840e@linux.alibaba.com> <207ef46c-672c-27c8-2012-735bd692a6de@linux.alibaba.com> <9354ffe8-81ba-9e76-e0b3-222bc942b3fc@linux.alibaba.com> <20191127101932.GN28938@suse.de> <3ff78d18-fa29-13f3-81e5-a05537a2e344@linux.alibaba.com> <20191128123924.GD831@blackbody.suse.cz> <20191128155818.GE831@blackbody.suse.cz> Message-ID: Date: Fri, 29 Nov 2019 13:19:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/11/29 上午9:52, ηŽ‹θ΄‡ wrote: [snip] >> That would avoid the partitioning question completely, exposed values >> would be simple numbers and provided information should be equal. A >> drawback is that such a sampling would be slower (but sufficient for the >> illustrating example). > > You mean the cgroup numa stat just give the accumulated local/remote access? > > As long as the counter won't overflow, maybe... sounds easier to explain too. > > So user tracing locality will then get just one percentage (calculated on > their own) from a cgroup, but one should be enough to represent the situation. > > Sounds like a good idea to me :-) will try to do that in next version. I did some research regarding cpuacct, and find cpuacct_charge() is a good place to do hierarchical update, however, what we get there is the execution time delta since last update_curr(). I'm afraid we can't just do local/remote accumulation since the sample period now is changing, still have to accumulate the execution time into locality regions. While at least we should be able to address your concern regarding exectime collection :-) Regards, Michael Wang > > Regards, > Michael Wang > >> >> Michal >>