From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Gushchin Subject: Re: [v11 4/6] mm, oom: introduce memory.oom_group Date: Fri, 6 Oct 2017 13:04:35 +0100 Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> References: <20171005130454.5590-1-guro@fb.com> <20171005130454.5590-5-guro@fb.com> <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=facebook; bh=tXwtSOcfYLwvh3iZmMOjapkkENGMReU7Md40od88YU4=; b=mUQzSe4fO8wcR2PAnJn8y2rEpYtgFHkZ9Ohhv9yePLiBpaP203K5MHB1CvHa9OXzwsNq 0mWGiYm/kzAEfSqkFWJXAIt4CDYlPQNsBmTb2Wq8trrsJ1SFpVx9SdLprmUvepXyQ7mi vZrwQ4PxuusIL/Qr+l2kv/fNrNwEiE1PToo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tXwtSOcfYLwvh3iZmMOjapkkENGMReU7Md40od88YU4=; b=R3/c97s5pu/hNhbFe88HdjxFkAw5sR7yoLQXD64Zb6CzV06ePwUdwv8fHXLvQVqIII5v7ehoMkTgJZP+3AJtd4+SYkVCZLBku1iNB+EXyd7XIXZrc0VNmKI1ndnkX7YQCiAyQKow328svxBqniovbXjYNuXHwM3mn8GIG9jJTp4= Content-Disposition: inline In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , kernel-team-b10kYP2dOMg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote: > Btw. here is how I would do the recursive oom badness. The diff is not > the nicest one because there is some code moving but the resulting code > is smaller and imho easier to grasp. Only compile tested though Thanks! I'm not against this approach, and maybe it can lead to a better code, but the version you sent is just not there yet. There are some problems with it: 1) If there are nested cgroups with oom_group set, you will calculate a badness multiple times, and rely on the fact, that top memcg will become the largest score. It can be optimized, of course, but it's additional code. 2) cgroup_has_tasks() probably requires additional locking. Maybe it's ok to read nr_populated_csets without explicit locking, but it's not obvious for me. 3) Returning -1 from memcg_oom_badness() if eligible is equal to 0 is suspicious. Right now your version has exactly the same amount of code (skipping comments). I assume, this approach just requires some additional thinking/rework. Anyway, thank you for sharing this! > --- > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h > index 085056e562b1..9cdba4682198 100644 > --- a/include/linux/cgroup.h > +++ b/include/linux/cgroup.h > @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p); > int cgroup_init_early(void); > int cgroup_init(void); > > +static bool cgroup_has_tasks(struct cgroup *cgrp) > +{ > + return cgrp->nr_populated_csets; > +} > + > /* > * Iteration helpers and macros. > */ > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c > index 8dacf73ad57e..a2dd7e3ffe23 100644 > --- a/kernel/cgroup/cgroup.c > +++ b/kernel/cgroup/cgroup.c > @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id) > spin_unlock_bh(&cgroup_idr_lock); > } > > -static bool cgroup_has_tasks(struct cgroup *cgrp) > -{ > - return cgrp->nr_populated_csets; > -} > - > bool cgroup_is_threaded(struct cgroup *cgrp) > { > return cgrp->dom_cgrp != cgrp; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f200.google.com (mail-wr0-f200.google.com [209.85.128.200]) by kanga.kvack.org (Postfix) with ESMTP id 774806B025F for ; Fri, 6 Oct 2017 08:05:08 -0400 (EDT) Received: by mail-wr0-f200.google.com with SMTP id y8so9396013wrd.0 for ; Fri, 06 Oct 2017 05:05:08 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com. [67.231.153.30]) by mx.google.com with ESMTPS id n7si1750607edn.262.2017.10.06.05.05.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 05:05:06 -0700 (PDT) Date: Fri, 6 Oct 2017 13:04:35 +0100 From: Roman Gushchin Subject: Re: [v11 4/6] mm, oom: introduce memory.oom_group Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> References: <20171005130454.5590-1-guro@fb.com> <20171005130454.5590-5-guro@fb.com> <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote: > Btw. here is how I would do the recursive oom badness. The diff is not > the nicest one because there is some code moving but the resulting code > is smaller and imho easier to grasp. Only compile tested though Thanks! I'm not against this approach, and maybe it can lead to a better code, but the version you sent is just not there yet. There are some problems with it: 1) If there are nested cgroups with oom_group set, you will calculate a badness multiple times, and rely on the fact, that top memcg will become the largest score. It can be optimized, of course, but it's additional code. 2) cgroup_has_tasks() probably requires additional locking. Maybe it's ok to read nr_populated_csets without explicit locking, but it's not obvious for me. 3) Returning -1 from memcg_oom_badness() if eligible is equal to 0 is suspicious. Right now your version has exactly the same amount of code (skipping comments). I assume, this approach just requires some additional thinking/rework. Anyway, thank you for sharing this! > --- > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h > index 085056e562b1..9cdba4682198 100644 > --- a/include/linux/cgroup.h > +++ b/include/linux/cgroup.h > @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p); > int cgroup_init_early(void); > int cgroup_init(void); > > +static bool cgroup_has_tasks(struct cgroup *cgrp) > +{ > + return cgrp->nr_populated_csets; > +} > + > /* > * Iteration helpers and macros. > */ > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c > index 8dacf73ad57e..a2dd7e3ffe23 100644 > --- a/kernel/cgroup/cgroup.c > +++ b/kernel/cgroup/cgroup.c > @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id) > spin_unlock_bh(&cgroup_idr_lock); > } > > -static bool cgroup_has_tasks(struct cgroup *cgrp) > -{ > - return cgrp->nr_populated_csets; > -} > - > bool cgroup_is_threaded(struct cgroup *cgrp) > { > return cgrp->dom_cgrp != cgrp; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752057AbdJFMFK (ORCPT ); Fri, 6 Oct 2017 08:05:10 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:41018 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751901AbdJFMFH (ORCPT ); Fri, 6 Oct 2017 08:05:07 -0400 Date: Fri, 6 Oct 2017 13:04:35 +0100 From: Roman Gushchin To: Michal Hocko CC: , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , , , , Subject: Re: [v11 4/6] mm, oom: introduce memory.oom_group Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> References: <20171005130454.5590-1-guro@fb.com> <20171005130454.5590-5-guro@fb.com> <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz> User-Agent: Mutt/1.9.1 (2017-09-22) X-Originating-IP: [2620:10d:c092:200::1:61c1] X-ClientProxiedBy: DB6PR0201CA0024.eurprd02.prod.outlook.com (2603:10a6:4:3f::34) To SN2PR15MB1088.namprd15.prod.outlook.com (2603:10b6:804:22::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e97be601-e897-48e6-9423-08d50cb27088 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:SN2PR15MB1088; X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;3:0La3c2RWLFkd4Jl0sspkvIz6FD4r/gXj908AzM60DavAC75ese7nY16Hm5qhA6Pj0U/EstbbbZSi7i3drKvZ+21nFNdKjsLPbaxPtjc/Zcn0DBA+ZPR0CxRshKsjhnA4IWZiLhhbmhObHy95Esv1nNFCn0A8NSBny4JwbHoAlPGg7xRZch4O7nwLEXk4TnE3UAz6pKQXYRrgK3NG1+WE2PJ2pH3TbfPbv+J1KjtTEUUrvsNv5BcNZtLpmHIpI8HT;25:LiE1UeaDzbE/Sz7hQ9KLQAI7O3kC+THyWmEO5OOreQRFB6K6SomhMrj8EdJUV5OBY+4VPUM8cVWNFs+jHVhvW2zYMibu9j/36dBxlFTXMnxL5KJaC212mOK6sIYTied/Y1M7lCrWsHJzu2h0sBV8Db6KH21q2dzTGQHgRl0JYsitgXUG2WxLEm4AeHRAW7oQT35MYvXG2Yb0knSKeQMRP9jvzvqEAvgLBxd0s1mnIOCCKG8jnWCU3/QFs0wMBOKi7WBw0jrWsDngQQFbZdpuYZjtYk59VE6vUGM6fQumI82CXpgUCHd+oCz0jt/d3BFAzpkxJqAaVQjM4m4SvKhdLw==;31:2P3oEqIrC7bAVR5haZ/Ye1prH0DzbKqBSMUQrO9v7bzJamZ/CqI9+h9PT1lxeiHPNVVZVKPWJfEazy4N8tP56DDaGFhvWoCbcmugw4QbMByG+NUgh4XNwnNL+zhVbzP+mw7vAj8uIJmBp8vkzKfmrs4+NnfJj43b1AiJraYuTyNI9O5EOf9XYKBWgzdvZXpgB4RCsSbebizj+iwmJMUBZtJ8K+eX5z86Xwc6/SuXwUo= X-MS-TrafficTypeDiagnostic: SN2PR15MB1088: X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;20:EEZD55c3dUskVa9+v7zEhyO0GFR1SbLu2tUQ77oYcqbTYBfERCxYAhu94WS0ca3nB5MzEr3JwpZXhAtGwFaZFUl7tS739gWvXAcDcirI/tA7bhr1r2OYSkZyLZMOSeKs6uuebvoYydfH2wvw8zIx6KouxWw713sqEjCEGwAeKdfO7Dh0aKMlDpeDOF5ISDCyYPh5hggUDIMMvd5uONFYztEYjlNJre2MXEjDgY2cXsuAMQqH+8SZgIO+KQRN4qHnRBD8OWWtMhdRgwa5C4wg/yMXp2E/s09vKXs0l5jaDqEQJGehvKechoyoO4eUtqhgxjPJJfumBRi6NCcSVdOovz7EPAyrgbux9eiJn8mrK3SiHiPDqdU4KzRp5lGYB5ma8MVMy5d+pNr5aUuZqnZB1Qo9TNUggRtA6dWgm1bilVt2eq0TpXnYbhbI++rJzqRHZ4fJVdXGxbP0ZG0hVu3M+/IIhojp+A/Z5Y8tzdljH63g0AmOj0mChZwYv40uOaYg;4:kjEFmYy/5vLlNle782PJ0d1nmSA5vdDHOL9vYHmHkHErvIYNlKbgDUASHDn20u4akyCnaQIkaDEfPu0ieE9l9kZ1qNuuEpYlRNBGnpiIOQKhNk5TdjCc+Nve4/TqI06u/ELxRBcvTWdsX5A+d02eOuNlj7pxbwoCRyYmLn9wEsNQWGal1fPB2sLdXfAyJS+4qlQ0ksTePLfWK1i2r1CXUlNtv7dA0goE6LDTvO+JkANrJtRHhUKwPTnq6h9IrptD X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SN2PR15MB1088;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN2PR15MB1088; X-Forefront-PRVS: 0452022BE1 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(376002)(346002)(199003)(189002)(52314003)(24454002)(2906002)(189998001)(54906003)(50986999)(54356999)(83506001)(7416002)(47776003)(76176999)(86362001)(16586007)(81166006)(68736007)(58126008)(81156014)(2950100002)(39060400002)(478600001)(6506006)(9686003)(7736002)(6116002)(6666003)(8936002)(55016002)(305945005)(6916009)(23726003)(101416001)(105586002)(106356001)(4326008)(1076002)(345774005)(6246003)(5660300001)(53936002)(8676002)(33656002)(229853002)(50466002)(25786009)(97736004)(316002)(18370500001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:SN2PR15MB1088;H:castle.dhcp.TheFacebook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN2PR15MB1088;23:3OIkS/M0J8niuBj2lMDltODDWUH9mIjKdWZGSWAG1?= =?us-ascii?Q?gBKPz7ZEeSQwqJ+xd8P9ycpfMnWZQhTx2GCgk697lWXlFu+EuCBiwGixHzKO?= =?us-ascii?Q?mUGOQtWsjlgoPiinb5Tlu4RuJF++4BWpwbLXR+H2z2WNA6LBdLk38GWR3HGB?= =?us-ascii?Q?H5zVZ5+GgbJJS/uam6DSpCEpxR8szF+vVAAwXUVfa0PT+SZFIp7yxAUCQSv8?= =?us-ascii?Q?94tsuqZBGYbQwxPnxMNBV2mAUzfTVQMa4qY75EAK6HsoNMeAWHd9S7me8lkZ?= =?us-ascii?Q?aW7ZybsAcpTq6mM7ZLi8fzwx0L1odQerkUA6BOo7bnwRBFkilF7edBGKvsGg?= =?us-ascii?Q?DP/zl9lYBsMa1xOGruEJDTJEAlQ8v4YbCnxfQKo9f5aY0ZEdbMMtzmAzYC0K?= =?us-ascii?Q?+kdhRCIvA5kaPnfJYDTGtUF9XRXMke2fvIFRdHanPvBpcYwtt5Kfq403SU9f?= =?us-ascii?Q?3TFg1gGUEktYrMRS5RQRR+eeXv0axvpca4S3wfZx/bwJnQ4Nt5j8v4vcspFz?= =?us-ascii?Q?WdwBt7xBMRH9aeflg9PCHzJ3J4zNsNNNH4xGo535BZYAfiawY/VNL2pHmkxz?= =?us-ascii?Q?RPSunxF2wOBu6eWO33/Bg7k1SSdr5P0JlEoB1eHOgHpRYkAMiD0D7h0s2kb2?= =?us-ascii?Q?QOpyoUu46GvN13j5g8JdCLopcsWAR1WBmaJbHeG0hHuYhgLDKu9bK7e0UgJU?= =?us-ascii?Q?265h/DgPhtwRGS5feqUzQ28+mHD3jqvtuhVwZkFrJ1qIJW1OMSKII0BKJYZW?= =?us-ascii?Q?DfmJ8S36ljrk07Ri5Efd2xw434c7NBGmBbGcc/s5cDRrtNNtrBssrzZ17twA?= =?us-ascii?Q?V7M+PjWPynfCYmaAXpOpJsed/Qh9nTii5c8EWrlgZJMhRZWl+eBf71n17PNV?= =?us-ascii?Q?oO2g+ziPoVFdo1BE4rLfzIwr+93XPv3wxN6Dbra4bacA/uGy4pVHavjTmRG0?= =?us-ascii?Q?Csu2YIMoxa8i86dC99c/GDyIv8VBksQhW4Z8FFXnovUaVVk78LFe9PYocZOQ?= =?us-ascii?Q?V3PkmJrk5OerFUND2S7eIKzyo5+SVrHD+db1E3r5AhCOZEFnoLD1FRKPzjIo?= =?us-ascii?Q?dr+9X1fCLkwWgZ49yrInlYvHZhNHSQX5pM1hDjTr9TexI75wUjBX7GTspXNz?= =?us-ascii?Q?+FGqnFaIrj1K6mZI9oCWDB0mq/f0YAel2quZvRn9D0ULbY3NHIrl6/VHg/FS?= =?us-ascii?Q?qOcISs0xmWkPtxjoeSyaNit6n/MqTe2GEHWy8+6100kgrGDjz/NHBm38A=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;6:cL748XvBWFTeEo5yQwQPwf1a8MAIBzQR6UtoEuW6QxQPh9/pbNAw2ndyFt0B6gK/ca5vUSFzY16veCZJsBaO6Qm/CpyjxILd8NgTBh4jV0HMt68aNP5lCkE1OKF/amZUW1/c6UZdFT0kMXsCBcHMK7Fb3yheSfrp1NY2awmNQF7OJsmLJ7xNmtKsN+n9+frnCbFSswESAH4mZXEKrGv4nUFDRuglt2uFInsqBvaAVjwHP8gVwLsUR8mJG1Xg/MdNiHYQNUcV0j4Gup5vI055AHoM89x3My1lFBKZTf4BsxzKW9CiEzfE/NZlcJUm9bEy1bP9aPOfNbtIbvZJ7HP4dA==;5:DgE601r/xroQoqxStr5wkLKboiIXHPVJQ6vhiKhDkt0MJiWx3PhIemT2MuyergYlaUClomAieCmVQbz+x1NYXTs4HFCDXn1iUVZPG6/kLGW5b11LjjEqvKf09qtBgiARNUvDaseW2qzk+XNosU+ddw==;24:QQ0+ePo122YT0SZJV4yNcPqBogNzYJvbYSJ1GMLt4CxgpQgyXeXVX46zjlne6LHXDF0fu5X/X9YsqJ7Qo7iehoXpwPpiS61dd9tqqTFWtxs=;7:XMs9hECK73VxUpjRr2JfGnbUtC+5YDtAjZ0Jv6iy9ZaLmKCCSmxZ9w2djr8ExwSHowOKGNSfFEQcJr2h/zRtqoLsUvjQyNsCDWicZSs2u1nUrmSAyc7BfRPbEpO7/3lQJxJpa6eEKKqJMxp322RvC/O8VCNcBLAZKqXw5KhiQ8OMQUxvsaZVBSy5YZaO3WQC6tYxU1G+fxGB2RWwLmaHnc3To3lnmtVuBeLl22OM0oU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;20:CfY7h9fC6CvemiYW6kesJr2vGA+3B5qNyENzThyHqJ4sC8oleLmX/KszjbLxWwXwR7JIcWhBEuGJdU46dAYxJtoeUhR7CPwkamBCXrSshzGeWSd8IbsqyKPxoAGCECL14IJzh4fKiJF9SDuPVXFg/tbG+HNaKI8Ko0wZlJk05GM= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2017 12:04:45.4659 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR15MB1088 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-06_03:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote: > Btw. here is how I would do the recursive oom badness. The diff is not > the nicest one because there is some code moving but the resulting code > is smaller and imho easier to grasp. Only compile tested though Thanks! I'm not against this approach, and maybe it can lead to a better code, but the version you sent is just not there yet. There are some problems with it: 1) If there are nested cgroups with oom_group set, you will calculate a badness multiple times, and rely on the fact, that top memcg will become the largest score. It can be optimized, of course, but it's additional code. 2) cgroup_has_tasks() probably requires additional locking. Maybe it's ok to read nr_populated_csets without explicit locking, but it's not obvious for me. 3) Returning -1 from memcg_oom_badness() if eligible is equal to 0 is suspicious. Right now your version has exactly the same amount of code (skipping comments). I assume, this approach just requires some additional thinking/rework. Anyway, thank you for sharing this! > --- > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h > index 085056e562b1..9cdba4682198 100644 > --- a/include/linux/cgroup.h > +++ b/include/linux/cgroup.h > @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p); > int cgroup_init_early(void); > int cgroup_init(void); > > +static bool cgroup_has_tasks(struct cgroup *cgrp) > +{ > + return cgrp->nr_populated_csets; > +} > + > /* > * Iteration helpers and macros. > */ > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c > index 8dacf73ad57e..a2dd7e3ffe23 100644 > --- a/kernel/cgroup/cgroup.c > +++ b/kernel/cgroup/cgroup.c > @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id) > spin_unlock_bh(&cgroup_idr_lock); > } > > -static bool cgroup_has_tasks(struct cgroup *cgrp) > -{ > - return cgrp->nr_populated_csets; > -} > - > bool cgroup_is_threaded(struct cgroup *cgrp) > { > return cgrp->dom_cgrp != cgrp;