Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbcCPPra (ORCPT ); Wed, 16 Mar 2016 11:47:30 -0400 Received: from mail-am1on0130.outbound.protection.outlook.com ([157.56.112.130]:57908 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751101AbcCPPr1 (ORCPT ); Wed, 16 Mar 2016 11:47:27 -0400 X-Greylist: delayed 1060 seconds by postgrey-1.27 at vger.kernel.org; Wed, 16 Mar 2016 11:47:26 EDT Authentication-Results: cmpxchg.org; dkim=none (message not signed) header.d=none;cmpxchg.org; dmarc=none action=none header.from=virtuozzo.com; Date: Wed, 16 Mar 2016 18:15:09 +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: <20160316151509.GC18142@esperanza> References: <1457643015-8828-2-git-send-email-hannes@cmpxchg.org> <20160311081825.GC27701@dhcp22.suse.cz> <20160311091931.GK1946@esperanza> <20160316051848.GA11006@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160316051848.GA11006@cmpxchg.org> X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: VI1PR07CA0117.eurprd07.prod.outlook.com (2a01:111:e400:7a52::43) To AM3PR08MB0580.eurprd08.prod.outlook.com (2a01:111:e400:c408::14) X-MS-Office365-Filtering-Correlation-Id: 74235733-def3-4c3a-3180-08d34dadd1df X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;2:Xa4PKejVRzfo/qbhug7mKh/c1qV+mey9eS4Hd5EsjdDVbJ0cssR3k9GWEdsFcXrAQgGKPd3cJEs8t8OngbOiLNR7GL/WCRaPzpeWr9csfgC79qqMtGw5xzx+HcFL+D4s4fWzv1KB9EgaIXstMjhEJ+tiXByodlZdnvF77jtdAlHfndwcn050I6BHwASY3agV;3:Zq0hpGnU83GvkOYvcxkQNRSROEe49MmLOmVbGPh+Hill8U27WvP6MQBnNHdMJh/6zSv0C/NpZLpkf7Hwxq7trlshmN3UoRTLMB5H7tuZwUqtGfs9BMHjnLb7m+CfeTQO;25:7jaURTrxvk/TEmjKTt/0Cj6RbjD+11TXcB2+29BGstB3tBCP1lqvETBx+pA29N4LgVu6AWnwcwT8hKZoQ0OUkAmw6rixLEyta3CQGtvU7Q63iHCuynTe4x6Jb0PwZgfych0faVjcSPoZEPIBlvASpD5I9wHhPojHr1vmz+dNvmtO93OYC9cq45YDF8AJOLosdFghC5Bs17gkf4F6qr7UMml+t6HujKPtqqKQadwa97VlR9mXI3mAstCrvLxyDFOC1slrLyuGv7De0/1IWIZH7+1Zs7LgA351t0mDD1J3MXaRA3aqGdYteNsrrtJbvQbmgZSpMtOtRH7R4BaItPW92A== 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)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046);SRVR:AM3PR08MB0580;BCL:0;PCL:0;RULEID:;SRVR:AM3PR08MB0580; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;4:S5Ir3Wn7/8ZOa7Z+pftyW/3MH49o8r5ZKzDeFXCmZTPhyNqwE+dlGtyLO6W2MxJHod+kvY/SmHe15rf59CdWzXWhbcVIjx0hlRwI117zUbaEmCLt1Li99USHzqsG1wvh+Ln/IaR2nU+fXBTTUJVznCwCFEawHQ2rVSi3to+IimQU+HIqonzRDeP1iHQyJo2fg6XRfDybvgSto/pWSY9aIW0AksjZX4eX0EoTzE37mjiFUT/SkMbuOhhU2zk33cYQ0GfDblMekf72RfSm0v1VVkHEfR9/Y+BMYeQQRWmh6z73S5Z7sCwmAamh/D7zOMv6MD8x5+xU1oY9uKNNyYkX1+OIGWFxhon1iW3DxbeBpkXXaY4tjYMgYXllMn43FuJqGFn5Fs6i1RlAO2JwpM03qs49Nh9E29mRLqAb1mnh2Uk= X-Forefront-PRVS: 08831F51DC X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(164054003)(24454002)(46406003)(81166005)(5008740100001)(93886004)(92566002)(5004730100002)(2950100001)(50466002)(86362001)(1096002)(66066001)(1076002)(110136002)(42186005)(3846002)(23726003)(6116002)(80792005)(97756001)(54356999)(2906002)(4326007)(33656002)(33716001)(189998001)(586003)(76176999)(19580395003)(50986999)(47776003);DIR:OUT;SFP:1102;SCL:1;SRVR:AM3PR08MB0580;H:esperanza;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;23:BulWuCqwIhyp2QmHfznTtqtfn2ysrqOWimrpHoOkpsIt585RMTgtiex022ZVZkCLPc7eSfcxrqVXNHh71mM6/O41gCG6u7dxYpLQhXPEcPDuLGsapvjvNyJl/FkSZsEZ3FOgQ13N4ZEaN31+GoyVH4X3xFzFdYtATBoAX0DqTyIvW3DKGxCyIeGylwSzbD22z0lX2IHsvmpuYuuwOMNYWwqP6yesX46pD1qIHH+PQHmwFlbe8pMRUMrHrfChHlbyKElENECXQB5xVqXGI01rQHKzgcJw5fxthoW9hDHEx8sGFnSP8gHOQb/J63hpk+ZVI6/K1CWAwHvJMetXOKaJdV0Px3rOdfcBJ6XMluOeboYFm7J3GBqU9sSuJ52qLVJ+IIK2nO1lh+vWM8HdAXgQKxOuinVNSm6utO0TPXJ0P1L47jrm6XtmRrOKBUOgSydnno/41LR3Ze5najj+frIuTlGKg2/06orCGcjIGCjAi1/e+WU+ebukV4melx5kb1+q9LgiXUEDCWe/5GGXhS6xJ/zPKtYYjtLcUkst7Qp/qO2277DVKgqBBapcb58SDxfuN4yMnsrizeWzXelMYMNJ9+FNVnRukcl0v16+ih6EH10mFw9+l9wL+HkLo9bJGlP+5NnKCg0YLygo9+ZtCkwAUOkM2+idnj4ODoI1reMNBL9x6x8YxW1OJcuEMyfZr5BedeH6mEV3+N18Cnx3CO4R9s80wdRN9wuCkkDDoq1wJ3E4TAeWNtA/aEGuP6rSpeTPchwRrNGgGPK/BlpYzoECPBDe7qe8Ba4T5AhbYsQezcdejM3gpY8pqOa09jdfFiIdTzvV7AgSZqcqr3pT74qVcgkD/JgcyEJsnYpEMWH45aXMOhVWJ62ItJiqIlUUipHeTwIYdIfrMAupdd1RfAOtz2tbCPSNwxqGsHl0QzamUbQ= X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0580;5:nfx0FVFnfzi0c0b2b0uVWl9UxOqJQ6Er2UYSt4/9+TM+YBl27x48UoesL+fEIOy3UsrhT78rdnq+YsGVAZprWxohJhWmqxIqUJENWVD/5xR6FdQPtI2QfWCLSHj0pQwmvjzKF2plXuKk34QgxAf0qA==;24:er70lN+Q3jOiGO8JACoCP0fjVi4ZOgQhHilDA1ItsprPhttrAwvOzMP09nUSbx/Py16Go/DiNgSDk4A/51kQR1bEYQcUtqqz3knZsq/3zmo=;20:SKxIBYYc+DVD72CJ/ZycRkVTr94zbpToH0wl1fx0YJ/11ik775aci9+5c1V9gI3tsTrRIR2/U4khXVlr068FKp6mrqC2wmABQXUxYo9Ec+H44ETUJjkroQTzwgqdXXPqisik7HwDpyiqEFaaeQ1OG1mXLA7tydZqZfl98rCzE1A= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2016 15:15:32.6680 (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 Content-Length: 1391 Lines: 28 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. 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? Thanks, Vladimir