From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932717AbcCQIib (ORCPT ); Thu, 17 Mar 2016 04:38:31 -0400 Received: from mail-am1on0115.outbound.protection.outlook.com ([157.56.112.115]:24319 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753510AbcCQIi1 (ORCPT ); Thu, 17 Mar 2016 04:38:27 -0400 Authentication-Results: cmpxchg.org; dkim=none (message not signed) header.d=none;cmpxchg.org; dmarc=none action=none header.from=virtuozzo.com; Date: Thu, 17 Mar 2016 11:23:45 +0300 From: Vladimir Davydov To: Johannes Weiner CC: Michal Hocko , Andrew Morton , , , , Subject: Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage Message-ID: <20160317082345.GF18142@esperanza> References: <1457643015-8828-2-git-send-email-hannes@cmpxchg.org> <20160311081825.GC27701@dhcp22.suse.cz> <20160311091931.GK1946@esperanza> <20160316051848.GA11006@cmpxchg.org> <20160316151509.GC18142@esperanza> <20160316201329.GA15498@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160316201329.GA15498@cmpxchg.org> X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: VI1PR07CA0065.eurprd07.prod.outlook.com (2a01:111:e400:5967::33) To AM3PR08MB0580.eurprd08.prod.outlook.com (2a01:111:e400:c408::14) X-MS-Office365-Filtering-Correlation-Id: 0a3e0458-6181-4098-a356-08d34e3d791d X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;2:rfs7VKId8WLeWWMnpjlbDla5lPGPsN2tyVVP+Bjclr1iIKnIaaYEWb1gOw5fL3VpOMgEjEXtm5ZlaOIfG2kBCN2+HhSTSuicdo+82kWJ+7x0z9CUaob8/kTavSodLLRjeNFBqJCWhSP2P2gJdasJEzv3csz2EJgZAuqJbr434dwI5FTk1UCwMrxeAkR0UYU8;3:FtyT7M0iEw3ZzUfU38r21HJn0jL+BaSVDGnWlG+ma4JK7d3kET9s0y7A1wgdwHGEJuzwepFhe1cN/ZayxYqxzE9g5APG1vXleJNWEwtCELa44FZ5kptmFPPLVL7CJiXa;25:mGgC4XBA7akmS2YzqqqcoMokiK6QdJmjLE7ndllUp5OrOedUFbWO5vBC6vEFOZ4fBzSxDVl0qWO3ags1JBalq/JSxvKp81e6YprjAyT4WtD1zl0aktFTjEDs4bs8zf8w30FQUGTgkjr5+rx62wnzVkCC5VmVwo6JbWWHn9FGzOXb5BgcRCat0GJ6w3NbIkrrOC7/fwKu20YcJpfUg1s8EnlK+bOANSa++walokwNYEKaXAtB7muckihLQRytxZg+X5kaO32x2dQsUdXYcxLmq/x5gL2GDu8nEGEODeLKNl29RHYZt9XnuMiq/kCgaId1vds1dEM5EkKQeCjqihLfOQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR08MB0580; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040046)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6043046);SRVR:AM3PR08MB0580;BCL:0;PCL:0;RULEID:;SRVR:AM3PR08MB0580; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;4:cT6PPIFrrr+36v9+cemNrpT9ax4QwP7DLk9RxcGisP1A4hHW7ROj8HNJPCMzb3++SxGsBPwTkyHgplehiopqCF0tl8yb1BAekZEAQ9LoQijf6L2+RguIOwYgdmuUPx+EjtsOjVk1mXtHf/YGn7vdZ0dX6sVdUvvtRzn5ig3EcJOKNJlcNJdk3eZ7E1wPUGzmqZE/8+G+b8X36ol2IxDVTrF3H6plwk8phKFq+C3w2eXlO3/Uad9feV+NXCKdw454m6Nii0HHh0zPQqRy7QA5Pm9gztodwWxvD+p+ZuB96/nDMoPSD7hj5mxvG+mU1ek09slQKgDWQYPdvomyVvUctn6+JzYvQhLxFz6eiTMecgbm0cgkXdZoGPiuUANwgDCo2KXMYn75OpzogLeL8JgXb0QMdWpBAe5tDxljGtoVwcA= X-Forefront-PRVS: 0884AAA693 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(164054003)(24454002)(33716001)(50466002)(66066001)(4326007)(110136002)(33656002)(47776003)(81166005)(1096002)(23726003)(1076002)(586003)(80792005)(2906002)(92566002)(97756001)(3846002)(6116002)(42186005)(5008740100001)(19580395003)(46406003)(2950100001)(189998001)(5004730100002)(93886004)(86362001)(54356999)(50986999)(76176999);DIR:OUT;SFP:1102;SCL:1;SRVR:AM3PR08MB0580;H:esperanza;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;23:it9bXLFtyYOYk1KgyUHnOngnstZgvobMos432sXUBt7k2WRAFzhbbgzywpae/oPsA6xezAdKZ/JDW5EAutBeIuBc4mcW+RL7QrIestMkipyx1tv8wy6vIa0IglW4/yqx9ocuduSi/8MTzyhMueQPd/1S0vFCBL7Uxv98hH791YPuAizGVfcqxNSZRznIl+iZhjC6wc1WDc8UgMkyX/2g9Ny5NoblJg040v0SI8gwp4avJr1W181xJ1R4/AvCCZz3WxfKx35OjpVV4LjNpFrDCJA9qPZPX7GvKEOpgviE9KqZtIs1Qu0bpDJyuH+6Fy3psDaYxCnWxWoYxH2Omq2PWMhGQQpE0CJ8I6x20wyMuIPGWGLxnz852xPbnZNhZa+Y6o33m5Rh+BhQdx8A4Ptp+gzho45CuhIlhCzSKDnKynkwdIxYponaYsYB2qnCp/EqKuMe+J1QwwryTPRcAZJGkhANrLD3ifyT2WVV0M4Yi04E55P51E3N8bb2F1izmBBa5HK8WjhUilrosrjcwZj5+pTIcoiuWk0IyX1Qoip1B+Z7UjZoPyhVLjcXMx0EMUh7DsfKSFVzox3HzsOYTzarGLZRkGID+6Ij48Ik1M0qFuQtXp2/c9rBjDmk+fs4DDO/nMLKckqmktZTo3dwJt4ye8cNbaasDB55VIHiAkuV1f4BSFv2B5ClaXPYwxOzC9Gw7zYVQCNnAuLJakvRtcdgyST/q9AvhuH/DGimbz+fFE5Y8xWakxob1xO3IL7fT7EHUC7pQZyqikioANLh4t91ka7lOO7///hjJRAADmCORCJtUSgDAEra6i9SY6eiSsfa5lZLi6s3MnmxxpIrgRaBLsSAfRkTjm64eUQxlRF870crVWLKJREBaIRY470CYwyjXn80N9EFIH8J75xxS8eoBTQY+VAtbVSSZcGYruYJ51k= X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;5:7nsMblvLIsirX9NCGzpAzNmBDqWgPgMe41wLLFNE1grfFLZhYvn9psOJpyus603qUx7YcXeEe1VN+gb2rEdOGcUJPRlTV+d+8OWbtNUUTVfLUdyHbnj/Sm4bVYlr6+Hi34GZFIe9qESkyeAwAsBn3g==;24:XD0+O3I9nSGo83A1oLo2UuvGblZJ5u7o4ttS/p3w8kVItBoUPZ2Vta5+FHuHqT9zRtb/UScaogHna9+zp9lWeJkvY0qEOmSP08j9sRpKPZI=;20:SWwNb9ToyojvDXzMcYk4HrM8XA9+//fJP/iODJT/UAq/chAiOHKqow6OQBpXqJPk1HjCU+l2x4lNXv+WT/aSuvpz24GOacr2G34K2hm/FSNHCR+j+x3pgz7fheCI3eXmBE9WZFzc7SBkbEHYO6pdIm789JZxU4fNPNm28u/6rYE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2016 08:23:51.2734 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR08MB0580 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 16, 2016 at 01:13:29PM -0700, Johannes Weiner wrote: > On Wed, Mar 16, 2016 at 06:15:09PM +0300, Vladimir Davydov wrote: > > On Tue, Mar 15, 2016 at 10:18:48PM -0700, Johannes Weiner wrote: > > > On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote: > > ... > > > > Come to think of it, shouldn't we restore the old limit and return EBUSY > > > > if we failed to reclaim enough memory? > > > > > > I suspect it's very rare that it would fail. But even in that case > > > it's probably better to at least not allow new charges past what the > > > user requested, even if we can't push the level back far enough. > > > > It's of course good to set the limit before trying to reclaim memory, > > but isn't it strange that even if the cgroup's memory can't be reclaimed > > to meet the new limit (tmpfs files or tasks protected from oom), the > > write will still succeed? It's a rare use case, but still. > > It's not optimal, but there is nothing we can do about it, is there? I > don't want to go back to the racy semantics that allow the application > to balloon up again after the limit restriction fails. > > > I've one more concern regarding this patch. It's about calling OOM while > > reclaiming cgroup memory. AFAIU OOM killer can be quite disruptive for a > > workload, so is it really good to call it when normal reclaim fails? > > > > W/o OOM killer you can optimistically try to adjust memory.max and if it > > fails you can manually kill some processes in the container or restart > > it or cancel the limit update. With your patch adjusting memory.max > > never fails, but OOM might kill vital processes rendering the whole > > container useless. Wouldn't it be better to let the user decide if > > processes should be killed or not rather than calling OOM forcefully? > > Those are the memory.max semantics, though. Why should there be a > difference between the container growing beyond the limit and the > limit cutting into the container? > > If you don't want OOM kills, set memory.high instead. This way you get > the memory pressure *and* the chance to do your own killing. Fair enough. Thanks, Vladimir