From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751504AbdH2SGa (ORCPT ); Tue, 29 Aug 2017 14:06:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56738 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbdH2SG0 (ORCPT ); Tue, 29 Aug 2017 14:06:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6352E8535D Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com Subject: Re: [PATCH v2 3/3] cgroup: Implement cgroup2 basic CPU usage accounting To: Tejun Heo , lizefan@huawei.com, hannes@cmpxchg.org, peterz@infradead.org, mingo@redhat.com Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de, torvalds@linux-foundation.org, guro@fb.com References: <20170811163754.3939102-1-tj@kernel.org> <20170811163754.3939102-4-tj@kernel.org> <20170829174325.GS491396@devbig577.frc2.facebook.com> From: Waiman Long Organization: Red Hat Message-ID: <73f65285-867d-8ec0-d81a-000a2d16f611@redhat.com> Date: Tue, 29 Aug 2017 14:06:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170829174325.GS491396@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 29 Aug 2017 18:06:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/29/2017 01:43 PM, Tejun Heo wrote: > In cgroup1, while cpuacct isn't actually controlling any resources, it > is a separate controller due to combination of two factors - > 1. enabling cpu controller has significant side effects, and 2. we > have to pick one of the hierarchies to account CPU usages on. cpuacct > controller is effectively used to designate a hierarchy to track CPU > usages on. > > cgroup2's unified hierarchy removes the second reason and we can > account basic CPU usages by default. While we can use cpuacct for > this purpose, both its interface and implementation leave a lot to be > desired - it collects and exposes two sources of truth which don't > agree with each other and some of the exposed statistics don't make > much sense. Also, it propagates all the way up the hierarchy on each > accounting event which is unnecessary. > > This patch adds basic resource accounting mechanism to cgroup2's > unified hierarchy and accounts CPU usages using it. > > * All accountings are done per-cpu and don't propagate immediately. > It just bumps the per-cgroup per-cpu counters and links to the > parent's updated list if not already on it. > > * On a read, the per-cpu counters are collected into the global ones > and then propagated upwards. Only the per-cpu counters which have > changed since the last read are propagated. > > * CPU usage stats are collected and shown in "cgroup.stat" with "cpu." > prefix. Total usage is collected from scheduling events. User/sys > breakdown is sourced from tick sampling and adjusted to the usage > using cputime_adjust(). > > This keeps the accounting side hot path O(1) and per-cpu and the read > side O(nr_updated_since_last_read). > > v2: Minor changes and documentation updates as suggested by Waiman and > Roman. > > Signed-off-by: Tejun Heo > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Li Zefan > Cc: Johannes Weiner > Cc: Waiman Long I just noticed that you have used my obsoleted email address in the cc line. Would you mind changing it to the one that I am currently using? Thanks, Longman