From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Gushchin Subject: Re: [v10 3/6] mm, oom: cgroup-aware OOM killer Date: Thu, 5 Oct 2017 11:27:07 +0100 Message-ID: <20171005102707.GA12982@castle.dhcp.TheFacebook.com> References: <20171004154638.710-1-guro@fb.com> <20171004154638.710-4-guro@fb.com> <20171004201524.GA4174@castle> 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=zesj9feZXq4myDzbj9dlKOjk5FYPCNKNAKwDCk5Ur5k=; b=HZ51lytsWfyNb18GClrp2FqcT4iorGc5nBxf9PNP7ZGtnbpCVmbyVBBAMLT2sDZsrW1P pBHHKqdrqu/Q83Zyall1YjHSPcZwluGkhbZ8xS9YbNduI0EZr0BzbecnQaSwVdD4Ywcz 5bXkMOVIxg8nhW1a/fq0Ex2W6doXOjYUHWo= 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=zesj9feZXq4myDzbj9dlKOjk5FYPCNKNAKwDCk5Ur5k=; b=ZnYQ1QpxEcdietMs0Wk17IV3egZ4E2bO2jTxfQ5pZr9G1eCeAcOc/bmr5imq/DNc+b1WDspmtpMtf0S4vL3ApeVnKkeVTeAEDOPfteEAtnLTk6mcr54uGFQHk9bY0LhnPSEI42oxjVJIt5uiOglrh/GjSkyZ2OquvRhpwIOVWoI= Content-Disposition: inline In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Transfer-Encoding: 7bit To: Shakeel Butt Cc: Linux MM , Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , kernel-team-b10kYP2dOMg@public.gmane.org, Cgroups , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: > >> > + if (memcg_has_children(iter)) > >> > + continue; > >> > >> && iter != root_mem_cgroup ? > > > > Oh, sure. I had a stupid bug in my test script, which prevented me from > > catching this. Thanks! > > > > This should fix the problem. > > -- > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 2e82625bd354..b3848bce4c86 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2807,7 +2807,8 @@ static void select_victim_memcg(struct mem_cgroup *root, struct oom_control *oc) > > * We don't consider non-leaf non-oom_group memory cgroups > > * as OOM victims. > > */ > > - if (memcg_has_children(iter) && !mem_cgroup_oom_group(iter)) > > + if (memcg_has_children(iter) && iter != root_mem_cgroup && > > + !mem_cgroup_oom_group(iter)) > > continue; > > I think you are mixing the 3rd and 4th patch. The root_mem_cgroup > check should be in 3rd while oom_group stuff should be in 4th. > Right. This "patch" should fix them both, it was just confusing to send two patches. I'll split it before final landing. > > >> > >> Shouldn't there be a CSS_ONLINE check? Also instead of css_get at the > >> end why not css_tryget_online() here and css_put for the previous > >> selected one. > > > > Hm, why do we need to check this? I do not see, how we can choose > > an OFFLINE memcg as a victim, tbh. Please, explain the problem. > > > > Sorry about the confusion. There are two things. First, should we do a > css_get on the newly selected memcg within the for loop when we still > have a reference to it? We're holding rcu_read_lock, it should be enough. We're bumping css counter just before releasing rcu lock. > > Second, for the OFFLINE memcg, you are right oom_evaluate_memcg() will > return 0 for offlined memcgs. Maybe no need to call > oom_evaluate_memcg() for offlined memcgs. Sounds like a good optimization, which can be done on top of the current patchset. Thank you! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by kanga.kvack.org (Postfix) with ESMTP id 25BA26B025E for ; Thu, 5 Oct 2017 06:27:54 -0400 (EDT) Received: by mail-lf0-f70.google.com with SMTP id o80so6615504lfg.6 for ; Thu, 05 Oct 2017 03:27:54 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com. [67.231.153.30]) by mx.google.com with ESMTPS id t9si8359662lja.339.2017.10.05.03.27.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 03:27:52 -0700 (PDT) Date: Thu, 5 Oct 2017 11:27:07 +0100 From: Roman Gushchin Subject: Re: [v10 3/6] mm, oom: cgroup-aware OOM killer Message-ID: <20171005102707.GA12982@castle.dhcp.TheFacebook.com> References: <20171004154638.710-1-guro@fb.com> <20171004154638.710-4-guro@fb.com> <20171004201524.GA4174@castle> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Shakeel Butt Cc: Linux MM , Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , kernel-team@fb.com, Cgroups , linux-doc@vger.kernel.org, LKML On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: > >> > + if (memcg_has_children(iter)) > >> > + continue; > >> > >> && iter != root_mem_cgroup ? > > > > Oh, sure. I had a stupid bug in my test script, which prevented me from > > catching this. Thanks! > > > > This should fix the problem. > > -- > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 2e82625bd354..b3848bce4c86 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2807,7 +2807,8 @@ static void select_victim_memcg(struct mem_cgroup *root, struct oom_control *oc) > > * We don't consider non-leaf non-oom_group memory cgroups > > * as OOM victims. > > */ > > - if (memcg_has_children(iter) && !mem_cgroup_oom_group(iter)) > > + if (memcg_has_children(iter) && iter != root_mem_cgroup && > > + !mem_cgroup_oom_group(iter)) > > continue; > > I think you are mixing the 3rd and 4th patch. The root_mem_cgroup > check should be in 3rd while oom_group stuff should be in 4th. > Right. This "patch" should fix them both, it was just confusing to send two patches. I'll split it before final landing. > > >> > >> Shouldn't there be a CSS_ONLINE check? Also instead of css_get at the > >> end why not css_tryget_online() here and css_put for the previous > >> selected one. > > > > Hm, why do we need to check this? I do not see, how we can choose > > an OFFLINE memcg as a victim, tbh. Please, explain the problem. > > > > Sorry about the confusion. There are two things. First, should we do a > css_get on the newly selected memcg within the for loop when we still > have a reference to it? We're holding rcu_read_lock, it should be enough. We're bumping css counter just before releasing rcu lock. > > Second, for the OFFLINE memcg, you are right oom_evaluate_memcg() will > return 0 for offlined memcgs. Maybe no need to call > oom_evaluate_memcg() for offlined memcgs. Sounds like a good optimization, which can be done on top of the current patchset. Thank you! -- 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 S1751639AbdJEK14 (ORCPT ); Thu, 5 Oct 2017 06:27:56 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:35632 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751318AbdJEK1x (ORCPT ); Thu, 5 Oct 2017 06:27:53 -0400 Date: Thu, 5 Oct 2017 11:27:07 +0100 From: Roman Gushchin To: Shakeel Butt CC: Linux MM , Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , , Cgroups , , LKML Subject: Re: [v10 3/6] mm, oom: cgroup-aware OOM killer Message-ID: <20171005102707.GA12982@castle.dhcp.TheFacebook.com> References: <20171004154638.710-1-guro@fb.com> <20171004154638.710-4-guro@fb.com> <20171004201524.GA4174@castle> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [2620:10d:c092:200::1:12a9] X-ClientProxiedBy: DB6PR07CA0014.eurprd07.prod.outlook.com (2603:10a6:6:2d::24) To CO1PR15MB1077.namprd15.prod.outlook.com (2a01:111:e400:7b66::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 260b49de-7ecb-490e-b745-08d50bdba938 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:CO1PR15MB1077; X-Microsoft-Exchange-Diagnostics: 1;CO1PR15MB1077;3:m3s1MUulufLcqbPNxfnRvgFIG499hcNQ9Ht0QMqj02kfPbc8r7QMsjwK7G/MurTi+rLA6oMagViJW5b/Km208H/lkv8OU9kAAgVhk5rKkoCfjadwmyyu0x8hozQLewqFqMpJElj4NDIIcBbbtF65fb7YGOKKo830J7/ForiipEJ9V7laQR/VsOA//VseWZN76JpvDxOyeHP05KapgxXA4KlbKTj1I3PLMVgLpgY+azKUjQokQn18L9OCmY6sqymX;25:I4JzNHQRegB+AulJ7KdPtp0ikUKJdlfKLjuwoZ36US4TFUR+aHFmYEMq+UCPNdD+pvVvIrLLSdM2PRh8Lkf4jRU/bb00pmZhi2qD0KwmyOfnqehho6mL87x0Ux5mCSEaySyLFVtZL8xWAiLI0ntMGfObYk2/S1IZ731uRM23/yX13VP25449juEichSjHvgYnnWIEW9azI2LxkilgwA+qRdRvudWh6p0HenYhyFfoKgPPuZof9fhwx1ly1HBY99kQBMZspBwmJeZQhRy4sGj7Rgnq+ETb7Nnp0Eei1CqdOUsrpgSbjU51VX+GvPRm9vKs1NpY4JJSK6X/HeXrHSN0g==;31:FCfNOaEMbFoGsh7YCKR+8c9SuroAqAkTnzP6m/xF31QZTt2+ypvHL6A8zZkighi7MODTvu8PIErTUUldlBoeZBgIDZ9xwBiVotFWFoXyC+nH749d2yIf3PQbUuv7nsmQqj6X6mPQdYnF2cZqyp2wAvuDqt64VZiHZvYgPmuMUYaDBhGDtKU3WOBS6BbD1baat1qh1K5TRBp98DBOAi9L1xNOuouIDGa3l8QD4N3B80I= X-MS-TrafficTypeDiagnostic: CO1PR15MB1077: X-Microsoft-Exchange-Diagnostics: 1;CO1PR15MB1077;20:OXYdpkkJvFehMhaBBAnzailaJ52NkC3x9VWUkumjI9D8RddAlUkX42R1tJHyjckvo1bc3YBKA+HRygOLJM8yxkuDStdBk/geHFbLPlLf7tzwxM6fSufMIDNVEWtJIzxl5MYL/cJO0mhtkhX5/U8RhWCFRIzUM7z8cF5sRB/x3UAzqeLZG8ksMJiXj0jrETeH5eScerVMNASQhnqOa57g5dPYEl6HyLD1mCbWhTEcuqxvVQRH7MnhTVesEhS33cPmfxl4G1vkj5/EygHQXwlLepIzCvyPA5NpZDruPUxAF5NTFnbb/its68vgQnSD/noFt0tEPruWOajm09YDZ0a9zUNK6c9f8GpjcguuMSeQiFWFe87Q3kndluL1dJRnIuvSypWrpLw+5KBzpwvbjCewR/YWrrXeSzSCO10N9eIzLCPohNDHCR49/h4+X46e0nOOFCwC3K+X3S/WOuqV+2binSsOAD5L2d/VQ9BP5OGkrUiFLtW14q0Na8PrT6iwBaIX;4:UHfzLy6PEVpl6fyOu+rRe1bdxtdzPrK1jNbTYOcAuk7ddojOcXe0BxljS0H05WzyX7iV1gAL+OyYlWPZV9rEqesKk5+/kN7/0+/ev3CPVn1MmF10ghWMPZN/tay/m/vr2PEHa3FUqu8ixxebCnCwHBhNko+ii7te99h0rBqPzJD0+KD8jSU/WYGkuF5KvsgdxdU6EHMI7fpS1zN3epk/O/NDRHpc/26Nkq7urwuzf3reW69sRFYqb3M6hPr7tKE4 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)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CO1PR15MB1077;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CO1PR15MB1077; X-Forefront-PRVS: 04519BA941 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(346002)(376002)(189002)(24454002)(57704003)(199003)(97736004)(6116002)(81156014)(8676002)(6666003)(2906002)(305945005)(106356001)(33656002)(68736007)(16586007)(6916009)(58126008)(23726003)(93886005)(229853002)(81166006)(54906003)(25786009)(8936002)(2950100002)(83506001)(316002)(6246003)(101416001)(54356999)(86362001)(53936002)(50466002)(9686003)(6506006)(50986999)(1076002)(55016002)(7736002)(4326008)(189998001)(5660300001)(7416002)(478600001)(76176999)(105586002)(47776003)(39060400002)(18370500001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:CO1PR15MB1077;H:castle.dhcp.TheFacebook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CO1PR15MB1077;23:5W/BM4rFA1nwB8bjPFQ3+7MIIB+tpeyms6k2pEcGw?= =?us-ascii?Q?tAWHRb7ag7t5m1uMZalhPE1BM0LpCLrLx1pvmAIrlIzwcoyrvI8FXiWKHlQm?= =?us-ascii?Q?jX8IJwX9/pl92Fs+UVJNM412aYfmM7368qFtj9ewu8D72aYKNNhly5287t+D?= =?us-ascii?Q?mRAuTfTRP0Ch8dVEvR7Juq1Colg6vEglPf3+Ev0TMCW6NGtcv7U/RCNlyIBl?= =?us-ascii?Q?LlZ/KEdv8s76pmJ445LbQ2MUxC5iXjJsOa9gFAh0uYD9lzt70UKM8Smy5lyp?= =?us-ascii?Q?AjfB5XHmQ1IrAdvton2qfXNJUZXynAhKGDLwePetjw/xs6txl3v08MBQ26i0?= =?us-ascii?Q?DK7Bi/WDngj1X9cWuFoc22T8pWDqIMtqk3ptdaSoQPeVFp2kgUm5rLPXaa6o?= =?us-ascii?Q?s3/L+i9mE3lHn5DJagzHxM8VhMFjx1sUbsi0gzwcRv3U2mVXnXD3Yx4L7V+7?= =?us-ascii?Q?lexuCN3s9vNm21GITSA4/98Iomn0l3QS/9No6VN0lyZ+Cl9b/CGIB1jnlLLH?= =?us-ascii?Q?+OMsc5qIR46fwkal3El6rdSNlvB+mUOHd8gs3rJwLBarlBa2QqYv6CyUKD7n?= =?us-ascii?Q?ONrVgmpad4rfKosnjupsMxYxEpQCj8caK/TX3nOuQtHw4KKUYk+7mX2yMPU4?= =?us-ascii?Q?rzOEZPzgYOKEB+vfqyIHopEAqIwbN0dRCyb8atKI9CI5X47vCQZyZ4Cs+TbP?= =?us-ascii?Q?rguSWpKaxvxxItlgAjzJ4Pquji7CXejnxER5PbupZimYe9L/IPIfacelxVOF?= =?us-ascii?Q?08IAStJAq3XR0OObI+0XY8TOy9Fb5VYE3kVbcjupD+2TvaOgSYu4G6iR2YAI?= =?us-ascii?Q?/hnvlqWMr9HWw15psr0sWsWx8WF+VLXwVWnETfnA/TQjszLz1I+/OY+U6Z6T?= =?us-ascii?Q?WjdDXfA6sTeIguVA0ITl1GI9Qr/vVvj7WoyMdaknHo2tVhwEX5ldvhUnCZ0G?= =?us-ascii?Q?czZXaiCBp1uAyh5dGbL+GEWhIaA2JtJStjMqfQHiVKuH2piK+KFP0541xy6b?= =?us-ascii?Q?mi0HTcX6IHbsJAfN83kl07RegXQjZaTwa8I2AGDeh6kY7nJ0r4yEnWZ0yuA4?= =?us-ascii?Q?x/LDw1sAJhU+5Bi3PtazAQCECaQH3E6ihmk6l7sdJuPahCnUOSKKW6zoTFMp?= =?us-ascii?Q?dw9m0hPWnw21SJrg2U4ikmOW6lOc2+Bih+smUcnZJqtTdCYQUp+HtY7cqtYj?= =?us-ascii?Q?a/g+6ouV4evX0p+QLmzshEzyz1OiVBEcWyjzppGlihuvv/Fayi+BGkhEA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;CO1PR15MB1077;6:hLDlzQyL/lXxihsT2jCAdb5GCXP5D3XSbZeL1NX4sghOjmmiMNLlBj8SF3L2dSSJmt4GE4yhL4//NEczMCl63Rg2CmYtgDWiw/qYjUtSMzGSa/GDq02qYfOs4822kp9vcgVG6wF5m2ygIvcQQ/7i+Nb7ZEZzhJAEwKwILxBeSafneuRT4j0X6i+raWv4shiWHXwWj71vNEeC6tAvgmPXGAE/lkAKbq2+RX5H2MCA87AVuI61LTReo7fihPaUopNrnTIX1+1tCbU9ed/CzedVwoRjghZyrSmgKfqBoKOehDbysnDu4tXjdxpXaLh6U2oU5WVcqRG2xKyizxGdZopygg==;5:diyZODsKpC/1NFY8T5aM99+gP6dYfl0VW4HzYR8n8rOBubcRWTMNXP3hwHRoo/snX6OZlnUOh4VUQDnnA/+UEJza2E68ZbY1uhyVdM3KKWzXxF+LgblZmRrmyX22WLujrWnAKxTXC5m28LSsJADOOA==;24:eJJxOkrR2g/Rx6v20sGx5kiuO9IzEzNb2MGXJTrnqbBd8Ll7CqTG+CJjQYLvWk+3wPUD1JT/Xl9S3mUAjFuSp9abFYP9G78pLcvjLIQf6yU=;7:d+WxqCtyq2KkVopyXwaTkPa1wQEVaFwzSBfT195KYqDClVmRHIs1doXOaCeOs5wiS177FZyVZ9mPDQcJWkbmt4lZpE+qWRGb+xGrKTFYMB3UUCZFrvVgiuS1xm9TbsMGQZrdhQjO65UxPOyhkIqa4FmG7C8kCSAeH9uW1EsM5OB2J27HR+0xAimhg4QfuK+d+exrs6ros7tjEFqgB1HsHkleU+LV42PRjB1mC7qSbYA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CO1PR15MB1077;20:Vo30Hf22EXcn95fqrGqvoDWvP0P66KegaBjmaN2hsgRw0Y9ACsO6vfDTANn4XGn/tcfm4BPV/5mRXRcJWChS2xymSkCEdhZzsaThOIYCQqipSEw2mlkAyhry1L9N2N1nmwk0t3BqNF0Dq2Nc9xsB2R0QDQT2CPd9TFiycOC7cuM= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2017 10:27:18.3852 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR15MB1077 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-05_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: > >> > + if (memcg_has_children(iter)) > >> > + continue; > >> > >> && iter != root_mem_cgroup ? > > > > Oh, sure. I had a stupid bug in my test script, which prevented me from > > catching this. Thanks! > > > > This should fix the problem. > > -- > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 2e82625bd354..b3848bce4c86 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2807,7 +2807,8 @@ static void select_victim_memcg(struct mem_cgroup *root, struct oom_control *oc) > > * We don't consider non-leaf non-oom_group memory cgroups > > * as OOM victims. > > */ > > - if (memcg_has_children(iter) && !mem_cgroup_oom_group(iter)) > > + if (memcg_has_children(iter) && iter != root_mem_cgroup && > > + !mem_cgroup_oom_group(iter)) > > continue; > > I think you are mixing the 3rd and 4th patch. The root_mem_cgroup > check should be in 3rd while oom_group stuff should be in 4th. > Right. This "patch" should fix them both, it was just confusing to send two patches. I'll split it before final landing. > > >> > >> Shouldn't there be a CSS_ONLINE check? Also instead of css_get at the > >> end why not css_tryget_online() here and css_put for the previous > >> selected one. > > > > Hm, why do we need to check this? I do not see, how we can choose > > an OFFLINE memcg as a victim, tbh. Please, explain the problem. > > > > Sorry about the confusion. There are two things. First, should we do a > css_get on the newly selected memcg within the for loop when we still > have a reference to it? We're holding rcu_read_lock, it should be enough. We're bumping css counter just before releasing rcu lock. > > Second, for the OFFLINE memcg, you are right oom_evaluate_memcg() will > return 0 for offlined memcgs. Maybe no need to call > oom_evaluate_memcg() for offlined memcgs. Sounds like a good optimization, which can be done on top of the current patchset. Thank you!