From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751521AbdFFQAr (ORCPT ); Tue, 6 Jun 2017 12:00:47 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:57636 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbdFFQAn (ORCPT ); Tue, 6 Jun 2017 12:00:43 -0400 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; Date: Tue, 6 Jun 2017 16:59:48 +0100 From: Roman Gushchin To: Vladimir Davydov CC: , Tejun Heo , Johannes Weiner , Li Zefan , Michal Hocko , Tetsuo Handa , , , , Subject: Re: [RFC PATCH v2 6/7] mm, oom: cgroup-aware OOM killer Message-ID: <20170606155948.GA752@castle> References: <1496342115-3974-1-git-send-email-guro@fb.com> <1496342115-3974-7-git-send-email-guro@fb.com> <20170604204333.GD19980@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170604204333.GD19980@esperanza> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [2620:10d:c092:200::1:ba6f] X-ClientProxiedBy: DB6P190CA0008.EURP190.PROD.OUTLOOK.COM (10.175.240.21) To SN2PR15MB1088.namprd15.prod.outlook.com (10.169.192.138) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN2PR15MB1088: X-MS-Office365-Filtering-Correlation-Id: 6c892856-b4f2-4b31-e4f6-08d4acf51848 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:SN2PR15MB1088; X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;3:/5gUqSkIQXD01nsxKcH8Rrh5cWLVcj18Znw4MZXR4S+SrU9693dicSYx3BJABLW1F6Wgymd2PwUT5ljBwzgrHBaD54zsvB60keuGqUhswyzZ4GYMOF3mqk7az7uoyYhxoFhXRaE2Lu64FNaMzKrjPjhT0ODLLSEaOW4I8da+aH0JW1DbLKkRXYjKg5T3+BDkJyVhqTY85oY/do3jzhCh2ZS7fuYimJjH/7NjTqZayud7LUkbr/cZ6W44+IX+qsPtloKIKFKF6sBzDj1R/RI2O/WZvAP4acBBF5qjiMld5lMjGQ62S6mLZ5NMayr/loUl8y0QzGCqL6GA7gwFTwTc9Q==;25:Acq19ZhRPCArmv2FLUqwHR5OBPBEPWwRIDHvf8ThTTkAJ7hsyqenhk6advqlx7A/V1LJnCQohwkvNbt0SQs+hy6Nh0SACYu21YAI7dOQdL8y7Is3oCFDeilt1mfm9bogcFOLwqZ80S/xARCMTkR6Ef/lyQshv7t6ZPIi5hlPJWB0jn+Gdqy4bauxwwr6lXICirPOwYdyKhyNeioMyPCzDziKWvEvEEARHjkSTfTXSXyNob085mGWtpB3YIfDLH+CUXZFNv7j8iTDf/5n52WpSf9lNOR4cR5Wo2ne0n4dPYyCUKA+502uX/nmy+/0BOqXb81DGzmBjjR5l9frTfOxLyhF0y2HNrqaeChdyA1wnl1iRm8MLFCbwtu8nKeHXwTdjGl4eezITEjAxeQmCTw20SMTYCfO8kM+GQ0XeHDrfia8/1rKOT1mF+n+bntahKA0X56k3XsBAl/7RH1GI838sIcVH5i8FD7xF2f2AdeV1HI= X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;31:77K2nMCksLUI7E5ZtBC+DyhL8+3j9zXLa73WXXwSoJHXDIQasgvSSF0fZEyI0VfDfuRZCQKcA4EZ4PBBk81nW5gYR8yhl6t+BdDHgKYGLc8SUfuxl+FXPF+70bZm6r7IG7Hy7zCLKGaGpRqFI/VArIhuC519+e3d9pU/QeLnYowPCf7UVkGOTznQqJSYU3WJr7CnDr7PKfOtp9TGc2jBa3lsmzbPh/GztW9VAStmsxU=;20:PyfwdRxEIO6YdT62bf+5PgeozjyKOivOwQ1ARqUxUdAfnO0XQ0JsceSkuQ8k697IoFdWuAYZaN7/IWAE8lqpT9tmvL6W2qaaXUArV6xsmXyEYsDJLzrQ4jdOWDJ+KWrsBCYsd+KZB55Xwq3Zu3GOh5Fj9w8VvHz99tfLLESTBbO7LSND586cuh7SOmqm1pvDfQnvk5rwPq8bXx7zoLDS9YBnCEbAr379mCavb0HGTu7g4ej6qP/7fJmQ4BfM5k15Fa0dvB51iYOuPcbScXD1qOOJpkMnt7EvVdOHoNTwx58Oo8J5OXA6z9TCuevtEao52hHKfVDvvj3PQOW3ZHmIL4LfvQ/ET3Ehm62bNwfYHYXnOMJlNWrGZg0eXr2OJkxhLstLtUY2nQyI2L14h6qi1qbipjNn2CfJB+V7lPvMPNTq1n3jX2qIDO+mOOq7fOrZDQYNagbzfFtpV8iaZii1UXC/B6iFsWyhM08AydLnbqXqmEzZw0rB7mbTqhAfDY3U X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(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-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN2PR15MB1088;4:LzXXcFPjzvjG54urpUGbKTTP4fzBdybrQKqNq3BGra?= =?us-ascii?Q?hVeHNRphok6NT6ZjJwq4OQWWETgDjV8qe54QHUSEJIECLLfVmx8SibOW5cGk?= =?us-ascii?Q?OGs9vTUfc5znVXx/v3Rov+PQzDr9iBge9H+BNGb0zv+TNkV1XtJ1vrFPZSjR?= =?us-ascii?Q?3/K9w8Fg1RSvIk4S6bhHYKTnD5wp6ogjHQmd1+FJuvguvitLWlUZshtwZUWs?= =?us-ascii?Q?pcX0cKZtvGn7k3p5llJrTmG2V4Pm1SYTT17VYRWqsAA+dwoWpPO9O26CuUi/?= =?us-ascii?Q?wd8fCB07gfvuTSTivVc/NnqybRDHqWbu+MH2f+X8hGjXMXcuBcHkS0JEgdZh?= =?us-ascii?Q?fK9GjB6/HhE3WCKKBuvGXYriJfzrYoqcBE+six/lQ+rXbD6NYWyQJVh78lNP?= =?us-ascii?Q?B3t8jQzYSWBS8yE+G18YQkLeVNNcUAaUXe/RR3JK/zckSrHCd5LdBNkygzTL?= =?us-ascii?Q?vO8K/GX2ZA0dzfh8ATkLM0Cm2UOestJQgexw+LxmjXqPAgIS2KMIJXUZgdu/?= =?us-ascii?Q?hKkQ8juDKw+JIZBAy+vixDUWKjVml2Xq8mqGmg89tlQ2J6xPSJLxtyjuztMo?= =?us-ascii?Q?IXLmwIn8d51UqtDSHoeqVTJOyhCziH1XDRmqGCqlF3iIi/7w/ZykJzZfzYCm?= =?us-ascii?Q?pcMx+oflnDn4jb7Dpu93ppGyZO+oIYNs62TS7ixTTHZ0MBhJbr36gw55BoZ3?= =?us-ascii?Q?R5SyGOodLyygVxtUygTcGuxYx5c7cy757RKti/+S2LBbrU/LJHstvPZWClw2?= =?us-ascii?Q?ounlzsAacdHEYyvShfqWFGZ/lDq1uBYCRqmIUX0UETgSMbzQzcpq3cfijIQ5?= =?us-ascii?Q?FJtA8MkMt7NpyHsVG+Y6wXi6FYRIzRYqz/PUTEBRr/4KnUOKv0PN+t+6rTdu?= =?us-ascii?Q?V9DhGS3ek9RhAdYepI30lQCJW27c+HtfA7O1YPJWDSSiBs4bygzuByjKtHdO?= =?us-ascii?Q?tQ3Wti4LmFOq7jyDEmUUAnpahOQlmheEQehiwB2znhnLKeL8Wl58x0S2/uIf?= =?us-ascii?Q?s3W6oU5QD86yIZ8BqoNAKk/XdoPzWg8SWKMibGvK0Y7dkLY6KHJ2OrwCMFyr?= =?us-ascii?Q?9uol2tP+q6sYCzllHx5pnsilUVqjSegOOQ0NQnHXHtZ99sk+ZH5OO3nu87kN?= =?us-ascii?Q?hYSbkgpCwTPm6LpcmJuySnjyvxmAMJ?= X-Forefront-PRVS: 033054F29A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(39410400002)(39850400002)(39840400002)(39450400003)(39400400002)(24454002)(54356999)(54906002)(6116002)(1076002)(110136004)(33716001)(42186005)(6246003)(83506001)(38730400002)(2950100002)(2906002)(9686003)(86362001)(55016002)(6496005)(50986999)(76176999)(6916009)(7736002)(7416002)(305945005)(81166006)(229853002)(189998001)(8676002)(4001350100001)(6666003)(345774005)(33656002)(53936002)(23726003)(478600001)(47776003)(4326008)(25786009)(5660300001)(18370500001)(217873001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:SN2PR15MB1088;H:castle;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN2PR15MB1088;23:oYsV/F3MAD7KFDC/PxCjUABvQgnahf96s+Rgo6z4T?= =?us-ascii?Q?dje0crHwOEbz9Esrzv3+5pvFmlMwawEfGLlQD5PFYmJE+cg6PPYrWzTNOsac?= =?us-ascii?Q?zke9/+yE5Iv1rJXcBrh+GHl6Uq3MhI6m9t8SRmUXR4YmscCOX6wBbD+XTDC4?= =?us-ascii?Q?klsDcn0Y3PaEtBsQ6ohG96+WFPfY20DxL6DnhInQ5jk9SCAWQZV+C+MHP7CU?= =?us-ascii?Q?PorD9U2V/pzmlYwx6xgFIk35QNU6XYNqfTN0fTvOBYOhJDyHMGXJo+znquQu?= =?us-ascii?Q?QP1RRGc4/WS6ImDHx63SEE+0rNdQfQjpdnQEMowWEMx7Eg9v7xGW5jTHGhPZ?= =?us-ascii?Q?uj8IT+rZPvjfFQ1sPmYl72CWiT37XC2AtDWI9sZERYa0InBxp2oPKj+KaVMd?= =?us-ascii?Q?t6LhkiTkxBUvjO4iSZFMMtRWns5dtlJ+PtPDaROv4/C/ltHazslF6TzjMzae?= =?us-ascii?Q?NSGL1Zg2VSnY7df3sLyjJ86M7ILj/0IP2ZUu3dVydOuKSQnjcB5vpkt6lpHx?= =?us-ascii?Q?RVUbohfNfJWt6pkEZTiyjCEGff4rEHq3bcUfLcavBPkLnbXmcdCC91uP7eWE?= =?us-ascii?Q?tsQBFLHn/jhig4V6C/PyBEKIgxCKL4iCivNNaKIHkOQ3aYrF8A2Jbfa7FkGg?= =?us-ascii?Q?dSYkYOONc82OBz4ADBwUJBm+FDdr9zmyd15UFGK1WMQoIYMPEsIBbVOcymS3?= =?us-ascii?Q?ukpvEhlkQs5k30FIVkvJY2ayxTBgMp/PA1UgGf66jQDW2EVMwbAVm/XXfCK0?= =?us-ascii?Q?0pslTWIFtzvh13H626XlgpfP8OP9L14trcrYBPNaPm5llq/vz6FxncGzHNCB?= =?us-ascii?Q?51SWU3ZTygeNLhGx+KpjkLl3GnVcbmSuPdVzAJJEPcggIfkvwRw8gg12wmBA?= =?us-ascii?Q?o9DnTZDbos0Tus09a11vQ2h9OETZVpTDl9FZ3MldLLBc+suvXukhrkeBGWB4?= =?us-ascii?Q?wE+QN/xcBouLZD1ECJCiZ/sNAoEkpwfiift/at4l00MiJPZXzf2ujFEHMEpN?= =?us-ascii?Q?NHt1Sy2K7vhd49acGU7ILoDVxLEiM5PfN0jESbPKYfncprD+Y9dyUw74FlFq?= =?us-ascii?Q?4C83iTqlRLYi9YaPBb/1/EkwE8nuBOWketqLLHN6HCvg4i76VAex2JJE09h3?= =?us-ascii?Q?TMh3Dp3p8mk/vjteOrr4MaVVX1KZGY4ldErkcV5aHXjHKsezJStlYhcj3U7X?= =?us-ascii?Q?itT/hFocUz9wf0WlnGVqmL5nbkNOiKFP35O?= X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;6:TrxxRPUkeubkYftDwHnDosKxRlMPR8cJ4mLEUVZz/RqcUvX/dbREkYRn3W/jKWE3MtsiNVxkv6BYFYPyR4UBeU/JNrU8J107wBSWcBDrB10GQxelK0aHxXNd2F8F9wrFMK4Kl0kFmrjfNX/wFjsIDLmBQ97wUQfhtqFmn5GlIZ6ljGGiO4f1vgCQdn9/bqwuiO0cZhriX8WcOkh0UlHb7zJAksrbx2/gkSOuyRxpJ6biI3pW9ipIjn3qoE4aS3mpR50AxxEfClQZgBrIWwL9l1Hwoue7Q2e1BzrxnZLcCksgWiGEwJTnzVsNm7fCJuhaypHhcZJ3ZyVHsD6/5v3MrV7xjW5cbjgm+w2RmDU5DXVWn45Y1hfAEvEyF7wi4eYTJ9JeD4FUW1LFufEuuBuD/WLtMhzjN+3wP+vwLgsFCfsda70RQ7lcJydt3cuxEaxyg0SQThpnPGurszbDgdQK7wr8TJxcRrYTmKrSsmKKVt15vaFKkFLCj4z52QaXxD4Ozi5erAJ6UsmQ0sTyzqAyAA== X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;5:Bya7a52yD3z6i1/p0Q9sBa8WMsVCkK9DQ5kS3oqmTl4iStwnuSNeVmPlzn9H0dfIIoe+fj2PfJGinH+AWbCfP4vatNYYDVOGetdlumIBB4fs4X8TvHGMws5YtyMjYvCtLF+qZKBRgKIwSWNRSdIy6EDICkitYl+yWE6YB1TAm7kq6O4b43u7BZWWhxTUpjNwL8uSabFJcfF1WiWucRMswxxEw4N8urKSrjQCuNPTl+sFQLsR7IAqZN46F4ZA5wgfLTtu6pakqu+sThj2uxQcTtU8CdaEe3oDOhxeAaH6OpaCtqWY4Cr6eACV9tfOoWOkM7DhuaS0jBJ0NiPDT6ALDHj0xOJCvLshdx+5pCtarfbx4hpT1aTD7l04MQLtBaLfhb+UyqeswP/cZv6p2yLqCW77CSn/UEY57ghbfXItNWEcLvdSvW/a6bRB+MVj01wA9ery+0pXrB9nAux9l+rMEcn4RIug6Z7RF7RXuz726U+mfSczLs832UgetVZgnxkc;24:QFVZwaGNwPR8T9oL4rp9pQj765Dn82H33KSz4c9EY6G69vzHjvrAWUqAUag6wzc4ibmGz35Ez/gg4/JT5Rfhb/iqaLicLZRXcgeYUDJfQJU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;SN2PR15MB1088;7:l0ZbDDLt7kchf3Nhuf6drOK+yU/Cz0L9355slswZPXxCmP6RIgVYbMTclVTSjTMXOFoH5d1BYofeIAGmuDHp0ELKRBP37IRaszNoIggIL788MpjSazD0mFWEQ/PJBhE8zsKaKC4y8aye4xgz9n0GxoHkyWSZxt/+VTq+QG1DWReH3hMz7rv4yxZe6LMCGh+TDoI1C5nMbp81FY1B5u4aKfoXvLjmAHYamY7TSB67ZGdomESiG1A9yw8JR57Do3hYL2LLFBim6zDefblRo8joDtvcr6Qw2RXYD3Ko6dElXz2wCHE2eHlL/afB4ZeA2f29Gb8ZRJa6MHaVYNlr115BZw==;20:8VeBxoP8aB104qQzBXGXEgeHIzxLt70KJsZro4QkIr5/c7AAPAEUKy0r2yIbzl6SzKiJRCz0PJGcQ1rTcFiOKKl3Z/d7JCtW3BmDtqq9Qe5bxOlAKuIcdy59XMxtLBKVJF/+REdplz0tIPIsCb+1n8roVVVPLnBB2mi8xIKc/qE= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2017 16:00:02.2012 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted 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-06-06_12:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 04, 2017 at 11:43:33PM +0300, Vladimir Davydov wrote: > On Thu, Jun 01, 2017 at 07:35:14PM +0100, Roman Gushchin wrote: > ... > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index f979ac7..855d335 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2625,6 +2625,184 @@ static inline bool memcg_has_children(struct mem_cgroup *memcg) > > return ret; > > } > > > > +static long mem_cgroup_oom_badness(struct mem_cgroup *memcg, > > + const nodemask_t *nodemask) > > +{ > > + long points = 0; > > + int nid; > > + struct mem_cgroup *iter; > > + > > + for_each_mem_cgroup_tree(iter, memcg) { > > AFAIU this function is called on every iteration over the cgroup tree, > which might be costly in case of a deep hierarchy, as it has quadratic > complexity at worst. We could eliminate the nested loop by computing > badness of all eligible cgroups before starting looking for a victim and > saving the values in struct mem_cgroup. Not sure if it's worth it, as > OOM is a pretty cold path. I've thought about it, but it really not obvious that we want to pay with some additional memory usage (and code complexity) for optimization of this path. So, I decided to leave it simple now, and postpone all optimizations after we'll agree on everything else. > > > + for_each_node_state(nid, N_MEMORY) { > > + if (nodemask && !node_isset(nid, *nodemask)) > > + continue; > > + > > + points += mem_cgroup_node_nr_lru_pages(iter, nid, > > + LRU_ALL_ANON | BIT(LRU_UNEVICTABLE)); > > Hmm, is there a reason why we shouldn't take into account file pages? Because under the OOM conditions we should not have too much pagecache, and killing a process will unlikely help us to release any additional memory. But maybe I'm missing something... Lazy free? > > > + } > > + > > + points += mem_cgroup_get_nr_swap_pages(iter); > > AFAICS mem_cgroup_get_nr_swap_pages() returns the number of pages that > can still be charged to the cgroup. IIUC we want to account pages that > have already been charged to the cgroup, i.e. the value of the 'swap' > page counter or MEMCG_SWAP stat counter. Ok, I'll check it. Thank you! > > > + points += memcg_page_state(iter, MEMCG_KERNEL_STACK_KB) / > > + (PAGE_SIZE / 1024); > > + points += memcg_page_state(iter, MEMCG_SLAB_UNRECLAIMABLE); > > + points += memcg_page_state(iter, MEMCG_SOCK); > > + } > > + > > + return points; > > +} > > + > > +bool mem_cgroup_select_oom_victim(struct oom_control *oc) > > +{ > > + struct cgroup_subsys_state *css = NULL; > > + struct mem_cgroup *iter = NULL; > > + struct mem_cgroup *chosen_memcg = NULL; > > + struct mem_cgroup *parent = root_mem_cgroup; > > + unsigned long totalpages = oc->totalpages; > > + long chosen_memcg_points = 0; > > + long points = 0; > > + > > + oc->chosen = NULL; > > + oc->chosen_memcg = NULL; > > + > > + if (mem_cgroup_disabled()) > > + return false; > > + > > + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) > > + return false; > > + > > + pr_info("Choosing a victim memcg because of the %s", > > + oc->memcg ? > > + "memory limit reached of cgroup " : > > + "system-wide OOM\n"); > > + if (oc->memcg) { > > + pr_cont_cgroup_path(oc->memcg->css.cgroup); > > + pr_cont("\n"); > > + > > + chosen_memcg = oc->memcg; > > + parent = oc->memcg; > > + } > > + > > + rcu_read_lock(); > > + > > + for (;;) { > > + css = css_next_child(css, &parent->css); > > + if (css) { > > + iter = mem_cgroup_from_css(css); > > + > > + points = mem_cgroup_oom_badness(iter, oc->nodemask); > > + points += iter->oom_score_adj * (totalpages / 1000); > > + > > + pr_info("Cgroup "); > > + pr_cont_cgroup_path(iter->css.cgroup); > > + pr_cont(": %ld\n", points); > > Not sure if everyone wants to see these messages in the log. What do you suggest? Remove debug output at all (probably, we still want some), ratelimit it, make optional? > > > + > > + if (points > chosen_memcg_points) { > > + chosen_memcg = iter; > > + chosen_memcg_points = points; > > + oc->chosen_points = points; > > + } > > + > > + continue; > > + } > > + > > + if (chosen_memcg && !chosen_memcg->oom_kill_all_tasks) { > > + /* Go deeper in the cgroup hierarchy */ > > + totalpages = chosen_memcg_points; > > We set 'totalpages' to the target cgroup limit (or the total RAM > size) when computing a victim score. Why do you prefer to use > chosen_memcg_points here instead? Why not the limit of the chosen > cgroup? Because I'm trying to implement hierarchical oom_score_adj, so that if a parent cgroup has oom_score_adj set to -1000, it's successors will (almost) never selected. > > + chosen_memcg_points = 0; > > + > > + parent = chosen_memcg; > > + chosen_memcg = NULL; > > + > > + continue; > > + } > > + > > + if (!chosen_memcg && parent != root_mem_cgroup) > > + chosen_memcg = parent; > > + > > + break; > > + } > > + > > > + if (!oc->memcg) { > > + /* > > + * We should also consider tasks in the root cgroup > > + * with badness larger than oc->chosen_points > > + */ > > + > > + struct css_task_iter it; > > + struct task_struct *task; > > + int ret = 0; > > + > > + css_task_iter_start(&root_mem_cgroup->css, &it); > > + while (!ret && (task = css_task_iter_next(&it))) > > + ret = oom_evaluate_task(task, oc); > > + css_task_iter_end(&it); > > + } > > IMHO it isn't quite correct to compare tasks from the root cgroup with > leaf cgroups, because they are at different levels. Shouldn't we compare > their scores only with the top level cgroups? Not sure I follow your idea... Of course, comparing tasks and cgroups is not really precise, but hopefully should be good enough for the task. > As an alternative approach, may be, we could remove this branch > altogether and ignore root tasks here (i.e. have any root task a higher > priority a priori)? Perhaps, it could be acceptable, because normally > the root cgroup only hosts kernel processes and init (at least this is > the default systemd setup IIRC). > > > + > > + if (!oc->chosen && chosen_memcg) { > > + pr_info("Chosen cgroup "); > > + pr_cont_cgroup_path(chosen_memcg->css.cgroup); > > + pr_cont(": %ld\n", oc->chosen_points); > > + > > + if (chosen_memcg->oom_kill_all_tasks) { > > + css_get(&chosen_memcg->css); > > + oc->chosen_memcg = chosen_memcg; > > + } else { > > + /* > > + * If we don't need to kill all tasks in the cgroup, > > + * let's select the biggest task. > > + */ > > + oc->chosen_points = 0; > > > + select_bad_process(oc, chosen_memcg); > > I think we'd better use mem_cgroup_scan_task() here directly, without > exporting select_bad_process() from oom_kill.c. IMHO it would be more > straightforward, because select_bad_process() has a branch handling the > global OOM, which isn't used in this case. Come to think of it, wouldn't > it be better to return the chosen cgroup in @oc and let out_of_memory() > select a process within it or kill it as a whole depending on the value > of the oom_kill_all_tasks flag? > > Also, if the chosen cgroup has no tasks (which is perfectly possible if > all memory within the cgroup is consumed by shmem e.g.), shouldn't we > retry the cgroup selection? Good point. Whould we retry the cgroup selection or just ignore non-populated cgroups during selection? > > > + } > > + } else if (oc->chosen) > > + pr_info("Chosen task %s (%d) in root cgroup: %ld\n", > > + oc->chosen->comm, oc->chosen->pid, oc->chosen_points); > > + > > + rcu_read_unlock(); > > + > > + oc->chosen_points = 0; > > + return !!oc->chosen || !!oc->chosen_memcg; > > +} > > + > > +static int __oom_kill_task(struct task_struct *tsk, void *arg) > > +{ > > + if (!is_global_init(tsk) && !(tsk->flags & PF_KTHREAD)) { > > + get_task_struct(tsk); > > + __oom_kill_process(tsk); > > + } > > + return 0; > > +} > > + > > +bool mem_cgroup_kill_oom_victim(struct oom_control *oc) > > I think it'd be OK to define this function in oom_kill.c - we > have everything we need for that. We wouldn't have to export > __oom_kill_process without oom_kill_process then, which is kinda > ugly IMHO. > > > +{ > > + if (oc->chosen_memcg) { > > + /* > > + * Kill all tasks in the cgroup hierarchy > > + */ > > + mem_cgroup_scan_tasks(oc->chosen_memcg, > > + __oom_kill_task, NULL); > > + > > + /* > > + * Release oc->chosen_memcg > > + */ > > + css_put(&oc->chosen_memcg->css); > > + oc->chosen_memcg = NULL; > > + } > > + > > + if (oc->chosen && oc->chosen != (void *)-1UL) { > > > + __oom_kill_process(oc->chosen); > > Why don't you use oom_kill_process (without leading underscores) here? Because oom_kill_process() has some unwanted side-effects: 1) it can kill other than specified process, we don't need this optimization here, 2) bulky debug output. Thank you for review! Roman