Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3138137pxu; Mon, 14 Dec 2020 22:42:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxJA2iL7NBrbq/fiRB99uQ/tfS/Czh/XjgBINrN8JhVrm5hrfEPe+yDcEHQtgZVIJgZzB06 X-Received: by 2002:a17:907:389:: with SMTP id ss9mr26314731ejb.158.1608014574383; Mon, 14 Dec 2020 22:42:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608014574; cv=none; d=google.com; s=arc-20160816; b=zYcFIROO8ZQ/DV1TmIyae93cMSaC/O8MN6PHsErsXbz7nObwCM7jwoIKQvrQ78tAkw 21h3ggQB/nwbbb/ESabvnRCA/d6y0vSQPXYS+itV5Zbnh/qbv1al59q1jfFYu38j8JSV q/Xnt1/qaI/uM9w/7GVL9sF1w5XBRCPZ82vGFNUsKEnJiN0VbkUwkZEk91GuFAu83z6S bJzMeKjTnkir7a9vHUiL5OwVHamJKjVyvP3Umdpa2z6CgDipf4GQanFv6PhqiiZfxzia fR62tLCNeRJylk48F0J0eUCDzouV51po4cZNc4eMGZSAAljXnvSrinak75QIvdP3PSPz YoBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:date:message-id:cc:to:subject:from; bh=pFiifUFHREcEPoMyFM0Iyg/jxsk3bw+lb48s5sOSwF8=; b=BZUURlqHbFfzqrF8pn0Qp1WeyOe9eQA50Dic2q5+zC/Mu4Uz3FMnEn/hKjt2q0JEf1 YAyZwNBIoQc44d7HN2U2rD0hx7deiAFdldDvjms4N7IMKHwCn0pR8CGWE+6yPRq3JC5c ohxkIpEytz6Xw4CMoJbBNrw/q27bgKSvmyTSIkMcdD4XLuxU72zsLe/vtcVmwIaTwJwY ucxCjsOaxEC1zAJjTMOW1vdcnWTvpSnQ0VvQOTQqt82EvLJFgi87pegv4HWKJDewhpRX rkVqBwnAFL6mvKuRFeHLm8Cx2Sq6xk5RD9J8JtkpBNTz3VBGAptUwgZbrJF4oCh6joyb l/hw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f20si399080edy.12.2020.12.14.22.42.29; Mon, 14 Dec 2020 22:42: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726377AbgLOGhp (ORCPT + 99 others); Tue, 15 Dec 2020 01:37:45 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:9612 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725865AbgLOGho (ORCPT ); Tue, 15 Dec 2020 01:37:44 -0500 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Cw7nc2Z8yz15fYx; Tue, 15 Dec 2020 14:36:20 +0800 (CST) Received: from [10.174.176.61] (10.174.176.61) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Tue, 15 Dec 2020 14:36:48 +0800 From: chenzhou Subject: [QUESTION] Dying cgroups in subsystem cpu, pids and named hierarchy systemd To: Tejun Heo , , CC: , Linux Kernel Mailing List , Yang Yingliang , "Libin (Huawei)" Message-ID: <35659595-5a3f-e0e4-1f61-15af6f1367e3@huawei.com> Date: Tue, 15 Dec 2020 14:36:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.61] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, When i do some tests with kernel-4.19.x,i found some dying cgroups. There are dying cgroup in subsystem cpu/cpuacct, memory, pids and named hierarchy systemd. The root cause of dying cgroups in memory subsystem is that some charged pages aren't gone. I don't figure out why there are dying cgroup in cpu, pids and named hierarchy systemd. I used to turn on/off Delegate and do operation "systemctl daemon-reload" in the machine, but now can't reproduce it. Is this normal and what may cause this or any suggestions about this? The details about the machine with problem is as below: # mount -t cgroup cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,rdma) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb) memory on /cgroup/memory type cgroup (rw,relatime,seclabel,memory) cpu,cpuacct on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,relatime,seclabel,cpu,cpuacct) # cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 12 109 1 cpu 10 110 1 cpuacct 10 110 1 blkio 4 109 1 memory 3 2571 1 devices 5 109 1 freezer 9 109 1 net_cls 11 1 1 perf_event 6 1 1 net_prio 11 1 1 hugetlb 13 1 1 pids 2 480 1 ... # crash vmlinux /proc/kcore crash> list cgroup_roots ffff000081272558 ... list -H ffff000081272558 -s cgroup_root.subsys_mask,hierarchy_id,cgrp.nr_dying_descendants -l cgroup_root.root_list ffff8007ff67c6f8 // cpu,cpuacct subsys_mask = 6 hierarchy_id = 10 cgrp.nr_dying_descendants = 1, ... ffff8007ff6726f8 // memory subsys_mask = 16 hierarchy_id = 3 cgrp.nr_dying_descendants = 2036, ffff800fb579c6f8 // pids subsys_mask = 2048 hierarchy_id = 2 cgrp.nr_dying_descendants = 1, ffff800fb57986f8 // named systemd subsys_mask = 0 hierarchy_id = 1 cgrp.nr_dying_descendants = 1, ... For the cpu subsystem, the dying cgroup is /sys/fs/cgroup/cpu/user.slice: crash> p root_task_group.css.cgroup $4 = (struct cgroup *) 0xffff8007ff67c010 crash> cgroup_subsys_state ffff8007ff67c010 -ox struct cgroup_subsys_state { [ffff8007ff67c010] struct cgroup *cgroup; [ffff8007ff67c018] struct cgroup_subsys *ss; [ffff8007ff67c020] struct percpu_ref refcnt; [ffff8007ff67c058] struct list_head sibling; [ffff8007ff67c068] struct list_head children; [ffff8007ff67c078] struct list_head rstat_css_node; [ffff8007ff67c088] int id; [ffff8007ff67c08c] unsigned int flags; [ffff8007ff67c090] u64 serial_nr; [ffff8007ff67c098] atomic_t online_cnt; [ffff8007ff67c0a0] struct work_struct destroy_work; [ffff8007ff67c0e0] struct rcu_work destroy_rwork; [ffff8007ff67c138] struct cgroup_subsys_state *parent; } SIZE: 0x130 crash> list -H ffff8007ff67c068 -s cgroup_subsys_state.cgroup -l cgroup_subsys_state.sibling ffff800faff65848 cgroup = 0xffff800faff65800 ffff800fa18b1048 cgroup = 0xffff800fa18b1000 ffff800fa22c0848 cgroup = 0xffff800fa22c0800 ffff800fa940e048 cgroup = 0xffff800fa940e000 crash> crash> cgroup.self.refcnt,flags,kn 0xffff800fa18b1000 -x self.refcnt = { count = { counter = 0x3 }, percpu_count_ptr = 0xfffefdf041334c83, release = 0xffff0000801c1ea0 , confirm_switch = 0x0, force_atomic = 0x0, rcu = { next = 0xffff80083365da30, func = 0xffff0000804fb748 } }, flags = 0x0 kn = 0xffff800bbdb1b110 crash> crash> kernfs_node.name 0xffff800bbdb1b110 name = 0xffff800fa54d9c00 "user.slice" Thanks, Chen Zhou