From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759917AbeAIQ6a (ORCPT + 1 other); Tue, 9 Jan 2018 11:58:30 -0500 Received: from mail-eopbgr10115.outbound.protection.outlook.com ([40.107.1.115]:14949 "EHLO EUR02-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752115AbeAIQ61 (ORCPT ); Tue, 9 Jan 2018 11:58:27 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aryabinin@virtuozzo.com; From: Andrey Ryabinin To: Andrew Morton Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Andrey Ryabinin Subject: [PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes Date: Tue, 9 Jan 2018 19:58:14 +0300 Message-Id: <20180109165815.8329-1-aryabinin@virtuozzo.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20171220135329.GS4831@dhcp22.suse.cz> References: <20171220135329.GS4831@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: HE1PR0802CA0019.eurprd08.prod.outlook.com (2603:10a6:3:bd::29) To VI1PR08MB2831.eurprd08.prod.outlook.com (2603:10a6:802:19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8901dfb-eeb2-4d1c-fc28-08d557822dec X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:VI1PR08MB2831; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB2831;3:43/ih0FtoR2WSeaCOHF6pRYYCqSFxCx7Y2VUPQenRWm61hnWniZP7VOTsRD6Piu4tFjT/dS0jUVp19g6yM84o+s7zLQeBAGaGeIgoxIX+Nbdd29GSL0isEv3aZBAmNIYER0ADN9bxXtmy+B6ZnLhsHFK//I9i+3BqY3OqKJ60fdJuqbgTh2rglOlWyyR7n94R1CjHmBDN2DvqOVtThGq8ymTyY4FGxJ7WM+TpaLIhTjyJ8VAUgfvRmRfH7+Kcdd9;25:QV40Spkr5HpyiKvZiohRAhQvGfbKlNNofuOr64H/i3JznIBYiq3UhQXUepSNOKPe94XCl02Sc7nJpc+94pY+syIApPqDEIA56U/+gdHggRtzSu5Qz7HKOwXtWel8OeCcjWN7Iy5kewQnmFyrB6ga7I38JEmiVQ6yqZYHEuxoLh8L6FdGms9tAPMfubkTGwlJYrUTLzGyQ9YDvdmJ/0pH2p9wz2NwdQZOKbEpQpO92KgdnNGMk6sGeUqs3R0F7pWTLfwC3JJ1f25KsgiNpDP62frUWjx70y/77SeMSBygy7LsQ6U54RqiJCk4Ewtp2tUPZ3QOnAQrfbKEN7AKHJONeQ==;31:eT9SR4iz8orXCWANGUR52mTUb3PAuX00WFqK8IJdcDDY9sumB0P+OQhQx/bOUTKLph7Wz2G1F4a8AIPW+c4Eqh8h6VjEHvdWejJ4wfpaoJHTjTnR+hwdfSa7NcO4nfgxLA4oxvwxl4iHrK2VqdiwnhQkvOAbuLNRQNR5qs2oXEpqcK+KqvZApze323l3VeO5eQkcVciNso2gkMapxTXDglgZOGW8huVdEscPOGfIxPM= X-MS-TrafficTypeDiagnostic: VI1PR08MB2831: X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB2831;20:cCSo/qTlASx639nagdpt5Uc5QzZqOnRpIboy0HqTJTXFqpvFGpWeoZyphn3br9yQklRhBFLu9FprnrLDUvJ4VNW0shBZi7HmIdwODQX7vjnZT0YLjAw5pfXWD5ZZvufGR6Yq5niXMmDezSGNemAYOxhoqcKoWM5EWw9NLFDCdCertUDCKCWSEa1EKBu6CMYZ5YW2O6a9vaXJNOYLFox3X292xn+FJjTy1DgTxJT40F+MZ7SWqAXPjjaaa6xSwDsP581+exWEC6TW6C0N1LWwQesaNjr1JkLECrnEmVYJAzcPNF+SzYtz5aDimKDMR2SrZQI2WDaqr4iC07kWHtpLzvWhfHPw5QTivVtKAgEe6NXnv+tjtMmMfaiTP8cE7dXYlD25XQEZ5xX5y5rTGuswQE8e1tysdLbDVMR8wsgdK6c=;4:9DVUDOD7T3J1uIHpoVu/jdmliNZ+vj3ozLq72JX/C/T0rP8mQQffezFbUkewkZlMeHrt2hAZvAtG7RwOZAOctsWwsOaTaO4p2YkXcnPRz32ktpfGElcxk67JJx/mgwt+Ikgs8nFx5mcksGEJEETQxaOwO77zJFhd53CQJPqHtzkxKMYUKnB6YG1TiFcTmZTGwM4WiQHSpCk+8glUdMWcKjh8VAd6wcj/GOXyzfGNivWbkNDwU3FgY66wdqPY22+WqSmL4Xk/i18B/IrbsGWtww== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011);SRVR:VI1PR08MB2831;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR08MB2831; X-Forefront-PRVS: 0547116B72 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6069001)(39840400004)(39380400002)(346002)(376002)(366004)(396003)(54534003)(189003)(199004)(81166006)(16526018)(76176011)(1076002)(36756003)(8936002)(6116002)(47776003)(66066001)(48376002)(2906002)(52116002)(59450400001)(51416003)(6506007)(3846002)(386003)(81156014)(25786009)(54906003)(8676002)(86362001)(316002)(97736004)(16586007)(478600001)(50226002)(50466002)(305945005)(53936002)(7736002)(105586002)(69596002)(106356001)(4326008)(107886003)(76506005)(39060400002)(68736007)(2950100002)(6916009)(5660300001)(55236004)(53416004)(6486002)(6512007)(34023003)(148693002)(142933001);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR08MB2831;H:localhost.sw.ru;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;VI1PR08MB2831;23:hJTesuutvYLfE7eFUMPgJLQO+iuN+t4W6ulY4F//Q?= =?us-ascii?Q?gLh7W0Po/Yqp8DyMsMbdjda8pIQAxdxs7Uv5MqFZsx1bHwTxA2bLf9QU6PJG?= =?us-ascii?Q?WHtVs4BKZvUz+aitWWQht4kqoZyfKj8e/gb29VELWuCax45RiOITujRzUAep?= =?us-ascii?Q?AfkhCmRl6cjepAPKpd9aDbHCQIPwkB3Y6Y+aDxoz2TLrmYwW39gJGvUTsmkJ?= =?us-ascii?Q?aqljY5ohgBDgBwOIYSvyQCn55UBnE1BeDX9Hmo7wkbGWaaRHgJwQ4cZO0VU/?= =?us-ascii?Q?ykE5L3kR2/AlcuL/6cGZdHeu6vaVdeel2BcwyQrQGu/Tdg6qpzQLRL66ChLO?= =?us-ascii?Q?jbaYPrYfwTxr4M1FIMlIdCPYaYdU3CJXYfY0VW2nverjaGY4mnmlC+lQdEaq?= =?us-ascii?Q?V9ALpIEf+LgJ/5c7r1hGTA3wrfGE05F/o7ytUoNdym+H+Uh9GD2+Ax6vg8Jr?= =?us-ascii?Q?oo9xsh1b9QTYqOF7jxWS6mMLnaOhDWrTLlzJUywsy+OAOSeYVAyrSUl15Zk2?= =?us-ascii?Q?lbuG6K//su/+iO9pVpJxKdtP3SSN6VekKnahxlI+B9Dt6aQhR6ZSID5U2+uv?= =?us-ascii?Q?g3hz/a76KuHGn7m+yegzrK1cWk/gms0S6J5fCu+73UINJIUxHxQlTho0FF6Q?= =?us-ascii?Q?EAEOzA2IEZe5Q0A28HUvoECFR3LJ/PLbvgs571k0ivjV4/6gzybSC/tGB6Wq?= =?us-ascii?Q?rl6G8vZBtmz97nHr7IR7V4ORcHuN4NWpPDQiKS4T+xBfdnhX7VHLz6+it6Hq?= =?us-ascii?Q?0CUtBWHwQNPhoArnD1SOYnjFt/mARCT2HMgOrbjrOzZQ+YfIW9bMT/VzVI9n?= =?us-ascii?Q?LU/BeA5HJLvC8FUtIDOy9jloQ4Ur3AEsbYEvKX1KXooKxrBcfi3/Wuw6bWGR?= =?us-ascii?Q?CoLMYr88gKt/rj3SCmHqDtpE4L5/RygG49/HJLRT2s83x8fFEzrH6hmA1n02?= =?us-ascii?Q?fUfXedOCQXTnjM0bnhVxKXK7BdCIexQ+7X7yczwtzCzadyNhLAvFrTrk4kSL?= =?us-ascii?Q?2VABQ9BAQxLtPgE+o1RJ+PNXWDA0ReYmmKdSrq+nGoFneuvkS/494hK0sX/B?= =?us-ascii?Q?xel10gXKDTzqd8/tFALDIrQ6o9uHiVhPZv/S5z2JNWINomAsiPKjTY+14Ot5?= =?us-ascii?Q?5DrR+lpaQbX+vasAXH4R73Mr1nIz/BOU6xrHDdwr6lgl1XDQCq5Rwar69LzS?= =?us-ascii?Q?pf52Z0LjAQCcB3sjVrZop+nnibAIPmSBsQN8hnErnqJl7no2MwS7YOR6Iw1P?= =?us-ascii?Q?yYuBgWX9fw/d/wRqnjzYGdEQTLht5uY6B9yxVJiiEL7OywLuX0K9vXszaN7L?= =?us-ascii?Q?C4Btx7Dnwf5hGSG+XJHAtHzwne3zVjbEjQd1dtlv7RmkDMBdpRQM9Q5/1xZa?= =?us-ascii?Q?dEAKw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB2831;6:pg+GDocZ2VyxHdgUdOMUsLvNY3G+h0By9qmGwNYYtmirC6uMKgw7k2sG0LgGM3Ru+CdfE6EM/VsanM7fYsSnrHbdlJ4lP8c4p4A5/yPh5F6pnACxYMw+avUg+OsQhp/1q1uh7mrUurirWVPx1MoXb/+w3Jo0UAJSS8QRiLWfqTXfAC7ZRmcjKuqbQPyWCTXyk5J0L8fgFoVWSsjJ20Smdd6bbZ5ANegRffKNXx1L1YAxg7rykYQ3kfrZZwfnnRW7KD6j4HtITPtAyAhayGBzgfVpdvaSDvmXHxQiMnBBg+DNCbrKSFBZZYP0sVuOmJCdzpntVX8GCjNBhDwyUNQUaxJi+gxIsNsSLp9OpPeVgRw=;5:+H7C5wbnFG6s5vQpvVK8eADTPVGu75Kf+13n7OiSyGCApp2ETkJYSHCumkpif2EsmKI6J0HMqIFvTqjwDcL9o6RE3yTtxUXltM6HwTYmCbSCUcV+6+64wn2gLH9+Mknd1xxD/XEtZrHRQo+xpTAIQclnbRNKDPxP/rp784d6cxI=;24:MnW0qjWU46XrpIfLb4HFUQbQGi0ZQrpG9peHimxaewCbIErxWTCV09oGYLcgx08jcwBavrx6rY2PtFKJgKjnu6+d7YObb+ZLxQ8lynbNuEM=;7:41vHcCKQ4Pprjs00XR2lKueBQlOF13dFlGR1b6/iexuhg7zBFRBQn2kV4XVdEHwckGKpCF6E9zdzmGRz8hivFeDvjJvPfauzclzV1BDkJ5QCSyN+uAs6GHLKRIUHccRVjniPD/PVzS89OmvpswDw1Vc5Z9krPExQq3k1aCw95gfqsSz9pzcVoDmHi8c1wpVvPsd8ewsKYqJ+qZ9Fb2ysC8h5qXZZ1vkx5maIWup/66eWXq45VJPNWiDd2NFkfXeN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB2831;20:cBlJjWovUQfFF4UmDcWK2pR26SIGDnsQEiKbDAv2SM13uGzCmX25SybfBjUefN5LTPbHdG7mAZOl8p/cipcY2nUXjVvSoY1xZPvMpO5VfR9sMc8+wQHL+a0HTaDFn85hhBbnu3vFXWwKEmZ7Lv0Jek5Wak3X3gy/8q2CJLVS3Ok= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2018 16:58:16.4101 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e8901dfb-eeb2-4d1c-fc28-08d557822dec X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2831 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) pages on each iteration. This makes practically impossible to decrease limit of memory cgroup. Tasks could easily allocate back 32 pages, so we can't reduce memory usage, and once retry_count reaches zero we return -EBUSY. Easy to reproduce the problem by running the following commands: mkdir /sys/fs/cgroup/memory/test echo $$ >> /sys/fs/cgroup/memory/test/tasks cat big_file > /dev/null & sleep 1 && echo $((100*1024*1024)) > /sys/fs/cgroup/memory/test/memory.limit_in_bytes -bash: echo: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin --- Changes since v2: - Changelog wording per mhocko@ mm/memcontrol.c | 70 +++++++++++++-------------------------------------------- 1 file changed, 16 insertions(+), 54 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f40b5ad3f959..0d26db9a665d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1176,20 +1176,6 @@ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p) } /* - * This function returns the number of memcg under hierarchy tree. Returns - * 1(self count) if no children. - */ -static int mem_cgroup_count_children(struct mem_cgroup *memcg) -{ - int num = 0; - struct mem_cgroup *iter; - - for_each_mem_cgroup_tree(iter, memcg) - num++; - return num; -} - -/* * Return the memory (and swap, if configured) limit for a memcg. */ unsigned long mem_cgroup_get_limit(struct mem_cgroup *memcg) @@ -2462,22 +2448,10 @@ static DEFINE_MUTEX(memcg_limit_mutex); static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, unsigned long limit) { - unsigned long curusage; - unsigned long oldusage; + unsigned long usage; bool enlarge = false; - int retry_count; int ret; - /* - * For keeping hierarchical_reclaim simple, how long we should retry - * is depends on callers. We set our retry-count to be function - * of # of children which we should visit in this loop. - */ - retry_count = MEM_CGROUP_RECLAIM_RETRIES * - mem_cgroup_count_children(memcg); - - oldusage = page_counter_read(&memcg->memory); - do { if (signal_pending(current)) { ret = -EINTR; @@ -2498,15 +2472,13 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, if (!ret) break; - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, true); - - curusage = page_counter_read(&memcg->memory); - /* Usage is reduced ? */ - if (curusage >= oldusage) - retry_count--; - else - oldusage = curusage; - } while (retry_count); + usage = page_counter_read(&memcg->memory); + if (!try_to_free_mem_cgroup_pages(memcg, usage - limit, + GFP_KERNEL, true)) { + ret = -EBUSY; + break; + } + } while (true); if (!ret && enlarge) memcg_oom_recover(memcg); @@ -2517,18 +2489,10 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, unsigned long limit) { - unsigned long curusage; - unsigned long oldusage; + unsigned long usage; bool enlarge = false; - int retry_count; int ret; - /* see mem_cgroup_resize_res_limit */ - retry_count = MEM_CGROUP_RECLAIM_RETRIES * - mem_cgroup_count_children(memcg); - - oldusage = page_counter_read(&memcg->memsw); - do { if (signal_pending(current)) { ret = -EINTR; @@ -2549,15 +2513,13 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, if (!ret) break; - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, false); - - curusage = page_counter_read(&memcg->memsw); - /* Usage is reduced ? */ - if (curusage >= oldusage) - retry_count--; - else - oldusage = curusage; - } while (retry_count); + usage = page_counter_read(&memcg->memsw); + if (!try_to_free_mem_cgroup_pages(memcg, usage - limit, + GFP_KERNEL, false)) { + ret = -EBUSY; + break; + } + } while (true); if (!ret && enlarge) memcg_oom_recover(memcg); -- 2.13.6 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Ryabinin Subject: [PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes Date: Tue, 9 Jan 2018 19:58:14 +0300 Message-ID: <20180109165815.8329-1-aryabinin@virtuozzo.com> References: <20171220135329.GS4831@dhcp22.suse.cz> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W8Qxe/xRwQnRJiHBBz/8X2j5Ks0UtQHdasLF4Os4OQ0=; b=HqsLwG9Xuu+3/Y86VN5XdpT7Ndt8HYk15Ti43LdQA53CgdLmInw6rRxGYUOeFVAjGgcAYn/l6BLdpXs+DMNur6Ge69OBYjZwIWvrCMX7gjb/SjBpdeLC2jyXdoWbQ0Lm08xsjz7SPsiYfj8sPIToHTl+am/Zquo+Ms7CKBE1Aug= In-Reply-To: <20171220135329.GS4831@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Morton Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Andrey Ryabinin mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) pages on each iteration. This makes practically impossible to decrease limit of memory cgroup. Tasks could easily allocate back 32 pages, so we can't reduce memory usage, and once retry_count reaches zero we return -EBUSY. Easy to reproduce the problem by running the following commands: mkdir /sys/fs/cgroup/memory/test echo $$ >> /sys/fs/cgroup/memory/test/tasks cat big_file > /dev/null & sleep 1 && echo $((100*1024*1024)) > /sys/fs/cgroup/memory/test/memory.limit_in_bytes -bash: echo: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin --- Changes since v2: - Changelog wording per mhocko@ mm/memcontrol.c | 70 +++++++++++++-------------------------------------------- 1 file changed, 16 insertions(+), 54 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f40b5ad3f959..0d26db9a665d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1176,20 +1176,6 @@ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p) } /* - * This function returns the number of memcg under hierarchy tree. Returns - * 1(self count) if no children. - */ -static int mem_cgroup_count_children(struct mem_cgroup *memcg) -{ - int num = 0; - struct mem_cgroup *iter; - - for_each_mem_cgroup_tree(iter, memcg) - num++; - return num; -} - -/* * Return the memory (and swap, if configured) limit for a memcg. */ unsigned long mem_cgroup_get_limit(struct mem_cgroup *memcg) @@ -2462,22 +2448,10 @@ static DEFINE_MUTEX(memcg_limit_mutex); static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, unsigned long limit) { - unsigned long curusage; - unsigned long oldusage; + unsigned long usage; bool enlarge = false; - int retry_count; int ret; - /* - * For keeping hierarchical_reclaim simple, how long we should retry - * is depends on callers. We set our retry-count to be function - * of # of children which we should visit in this loop. - */ - retry_count = MEM_CGROUP_RECLAIM_RETRIES * - mem_cgroup_count_children(memcg); - - oldusage = page_counter_read(&memcg->memory); - do { if (signal_pending(current)) { ret = -EINTR; @@ -2498,15 +2472,13 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, if (!ret) break; - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, true); - - curusage = page_counter_read(&memcg->memory); - /* Usage is reduced ? */ - if (curusage >= oldusage) - retry_count--; - else - oldusage = curusage; - } while (retry_count); + usage = page_counter_read(&memcg->memory); + if (!try_to_free_mem_cgroup_pages(memcg, usage - limit, + GFP_KERNEL, true)) { + ret = -EBUSY; + break; + } + } while (true); if (!ret && enlarge) memcg_oom_recover(memcg); @@ -2517,18 +2489,10 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, unsigned long limit) { - unsigned long curusage; - unsigned long oldusage; + unsigned long usage; bool enlarge = false; - int retry_count; int ret; - /* see mem_cgroup_resize_res_limit */ - retry_count = MEM_CGROUP_RECLAIM_RETRIES * - mem_cgroup_count_children(memcg); - - oldusage = page_counter_read(&memcg->memsw); - do { if (signal_pending(current)) { ret = -EINTR; @@ -2549,15 +2513,13 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, if (!ret) break; - try_to_free_mem_cgroup_pages(memcg, 1, GFP_KERNEL, false); - - curusage = page_counter_read(&memcg->memsw); - /* Usage is reduced ? */ - if (curusage >= oldusage) - retry_count--; - else - oldusage = curusage; - } while (retry_count); + usage = page_counter_read(&memcg->memsw); + if (!try_to_free_mem_cgroup_pages(memcg, usage - limit, + GFP_KERNEL, false)) { + ret = -EBUSY; + break; + } + } while (true); if (!ret && enlarge) memcg_oom_recover(memcg); -- 2.13.6 -- 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