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=FROM_EXCESS_BASE64, 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 43088C742D2 for ; Mon, 15 Jul 2019 02:10:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2004620868 for ; Mon, 15 Jul 2019 02:10:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729051AbfGOCKC (ORCPT ); Sun, 14 Jul 2019 22:10:02 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:36474 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727006AbfGOCKC (ORCPT ); Sun, 14 Jul 2019 22:10:02 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R791e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0TWte0iC_1563156576; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0TWte0iC_1563156576) by smtp.aliyun-inc.com(127.0.0.1); Mon, 15 Jul 2019 10:09:37 +0800 Subject: Re: [PATCH 1/4] numa: introduce per-cgroup numa balancing locality, statistic From: =?UTF-8?B?546L6LSH?= To: Peter Zijlstra Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, mcgrof@kernel.org, keescook@chromium.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, Mel Gorman , riel@surriel.com References: <209d247e-c1b2-3235-2722-dd7c1f896483@linux.alibaba.com> <60b59306-5e36-e587-9145-e90657daec41@linux.alibaba.com> <3ac9b43a-cc80-01be-0079-df008a71ce4b@linux.alibaba.com> <20190711134754.GD3402@hirez.programming.kicks-ass.net> <20190712075815.GN3402@hirez.programming.kicks-ass.net> <37474414-1a54-8e3a-60df-eb7e5e1cc1ed@linux.alibaba.com> <20190712094214.GR3402@hirez.programming.kicks-ass.net> Message-ID: <673993cf-c5cc-475d-1396-991edcf367ea@linux.alibaba.com> Date: Mon, 15 Jul 2019 10:09:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.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/7/12 δΈ‹εˆ6:10, ηŽ‹θ΄‡ wrote: [snip] >> >> Documentation/cgroup-v1/cpusets.txt >> >> Look for mems_allowed. > > This is the attribute belong to cpuset cgroup isn't it? > > Forgive me but I have no idea on how to combined this > with memory cgroup's locality hierarchical update... > parent memory cgroup do not have influence on mems_allowed > to it's children, correct? > > What about we just account the locality status of child > memory group into it's ancestors? We have rethink about this, and found no strong reason to stay with memory cgroup anymore. We used to acquire pages number, exectime and locality together from memory cgroup, to make thing easier for our numa balancer module, as now we use the numa group approach, maybe we can just move these accounting into cpu cgroups, so all these features stay in one subsys and could be hierarchical :-) Regards, Michael Wang > > Regards, > Michael Wang > >>