From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754571AbcE3JVK (ORCPT ); Mon, 30 May 2016 05:21:10 -0400 Received: from mail-db3on0105.outbound.protection.outlook.com ([157.55.234.105]:46544 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752561AbcE3JVI (ORCPT ); Mon, 30 May 2016 05:21:08 -0400 Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=virtuozzo.com; Date: Mon, 30 May 2016 11:47:53 +0300 From: Vladimir Davydov To: Michal Hocko CC: , Tetsuo Handa , David Rientjes , Oleg Nesterov , "Andrew Morton" , LKML Subject: Re: [PATCH 3/6] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj Message-ID: <20160530084753.GH26059@esperanza> References: <1464266415-15558-1-git-send-email-mhocko@kernel.org> <1464266415-15558-4-git-send-email-mhocko@kernel.org> <20160527111803.GG27686@dhcp22.suse.cz> <20160527161821.GE26059@esperanza> <20160530070705.GD22928@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160530070705.GD22928@dhcp22.suse.cz> X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AM2PR09CA0038.eurprd09.prod.outlook.com (10.161.22.176) To DB5PR08MB0582.eurprd08.prod.outlook.com (10.169.32.140) X-MS-Office365-Filtering-Correlation-Id: 5352a665-1370-417f-328a-08d388671b34 X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB0582;2:jLX9qgg9DNTyxEcnTutMLOkwmt1e7RydIoH0Dz1opwz/pKlgxc5geFxeGGcdb+KMl7NN3ob64wsevjalq2p5UIpfof3fq2fQfx4FCfpwXCtfnU8q9izr8rMM/kTVAUeP5su6katXzOfTu5ms5LEn5dBtqiUE/5QH5Qyb72FuLdopp7pU1yfvG43Stf9O1TKJ;3:hX41n0K0DwisEU3Aoq56VUxV1rrGrrtbf4HWBXY3G9oAZkNSwhU+gJ2sxd2GyUXi5GMCYmE7TeDwoA+oFFEahAJArBqAh1MWvUPoXFEQm5D4L79mt9I5Dmb7+m81PHIW;25:GzvInEWAcVGv2+iVPEl/cxmCc+ShjDx9U9WrA1YJ2lIsi48C6ZHizhUWRRccQiO8Ee9W2ZmbmWYi9DU5vieYnRT64A3uA3+1DBSDyYxOBYNSc+yufF9n/Ahq/ksagxnMpLcc7fTwx/hVTUIEQJPz7dQyWItA4IfovrjJtdE8/WY+uYlwS6jhBc8oK3NEHntjXknwa0t/GiuF6BWIFMDox7Nv51lRF2zBCVSo2O2mOmhg4kyyDu7FkNaQ76ylpp805hd1Zhtmud6nAs1+k86SVb5Jq3rX9Kr8TTErNM+CEt9Wf0qTzEbwCo2M4Zpcs2xwLYon66fFQgxevyiNaSHm7s7UCefjkNcsCBdupGK1E0iSlZQGFpB7SQatMd1QGmkmVSVK46Xd2M47mWydkaeKSi6HqiWKIB27PA78VnzSLn0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR08MB0582; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:DB5PR08MB0582;BCL:0;PCL:0;RULEID:;SRVR:DB5PR08MB0582; X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB0582;4:6rKbK0bjBcC2eJx3NR9+yOgazEXXN73VM7uZPMC8sCE9Jz/WlvkmYVPJg/Nbni4d3ZI2TMpa0jsX6KkAROEsroBLD5Gn+CXKzEgeQiXVh6Ii/8khj+Qx4eifPGA8AxJzfLOEcGHJ4VYkxlW2l4DJVPv1haRkRK9knJW8mC5GXVBBTL97Z9WPLc9NHsY4s9COCZFhlVTghPP6d+T5NcNepVYew8A5eqOaud/gbIE+KmsBL7SZyy4xrzfVkk745LCqKJa/FzFBLotn3NMQ9CH1At54k5uK0BiMWxUBZ5bdEvGtyRJd6eJNAhAzGOvBXL+QekK+m2nOMQbs7+dJhFo1rwjnPD6RCx5q/yIz6qHDAn9draCaaOgSSkFB5T3VeUq/mW7HsB0+t0UbYj+MNJZPEtG8vyo+ajo7OTAw8HqvAUY= X-Forefront-PRVS: 09583628E0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(377424004)(24454002)(80792005)(93886004)(2906002)(86362001)(110136002)(50466002)(189998001)(5004730100002)(46406003)(66066001)(9686002)(2950100001)(4326007)(92566002)(97756001)(50986999)(42186005)(3846002)(6116002)(47776003)(5008740100001)(23726003)(81166006)(33656002)(54356999)(586003)(76176999)(33716001)(8676002)(1076002)(77096005);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5PR08MB0582;H:esperanza;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB0582;23:pGmQ1eHAi2UWdihCNm88LB9/YuZcA2IBSzwT6ATfQBml3NlZT1mOFuCHOowSdlvuU58kPY7/TBpH1d3XDm5Ezxnint6Q0vTX8T/H6wffHgot6HUjLlnZBdo4d7wPdlUzL9LNiS2e9e54pC0d+Fu2yBBVia1gca4s1hIw1J4gU0dRMr5qx6A1AVlMOoxuDlDI+YxhIMxIohjNXY+fJkBKR9C+EKSK+krxqoD/GMVA+6fGzCbjRd3uPR2nhhm329e1xrxwDcv5uKkdCBjNzQOXrVSz0bSsAXwu+SdlIPQlMZj3KvA6qiHVl0FS38//f3Hu6fEzkL7rDyNJvWNmA79rqswrFCD/N53u2VhLts0g0e3t+jtmGRk3MLKMsfsP8rTteq9ZAfVO/r9/rwmyCHYLr28d76yxCuuBUpq183dfIuMXCcy7kYI95WUiUh/RC6/nbViURA904F6X8lhETi9dh7cS6nkl/waZ56E5+IkjooyzZG38s9yOnE617ERIPvpgil4l0IDkLYTe/+zfU4LUg1CfxNL7kG50GjiiE00POcyn8ZZa94FE9DUr/M7vStL8LAraB2/J0ly08lQjoK6i1551UXY8V+XNWYWA0mWcL/zrvYJbVw6qMB9YnrQeenfezb7O9vMqzvkqjgHTKuu0yiCDqMyGLLkMMOxvIaVFzf9VUlPSU04woZ9siVUTE9sUSgvWWUf4bAh05Lxbjkjj8WgJIN9bMNMyxbg+WHOdoxRIv88RHnEt8egfaNkAJev1h1+UymDBmSHMYpgC0096TABBnEfHD96ctWRwpi5Fm8uN7yTr9LUNUQaGobj2TchKzWRz9OF7zEhYggRVha/t7O6Xkg+3RMCJ0I7k/1F7WRQvj1w3BYuXTawRP3uBRvAib0qvFhx93PKHnXic+ZtJ6dH3r7tk1s+bvXMLE2tvyls= X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB0582;5:sxVrzYdnikjp4sSWdiABNmABKk8m0lzKwWLFB5sJ1tsIIbA8XA4Xebg/Dd2TOxunvG2pVOjs8K0AY/w5g/+l8ZM5QN1wLd9TY3KtPnpg1SQGIG62SFFnfi/R88U9L7qJ2aKti2Vc3Uqj6hQQCp6HGA==;24:qAz69hmh5JIqCEKNBqAdgr6RuWl52pwiraFfT7j7FVMLadbCjBpe1aj8VgXD2fCADRNR97gVYaydLM7b4YdazymEGnW0Epw9DGohfLNfqEc=;7:zcpHGib3qbD+XTiHfmaWAzxDWpOjWvZzYnBMvu+/r01NdjG4sh5nfeeQMAedkM/Kvikmb4AGkI177GPrAI6AOG+PEIgNKE2kE4PCGOslGMD+JkoeZA+lIh+ULJBFxzbzAR78v+HKrDH1QIdvTz7QwMwFlePzDUSykdwloCdMTJlTsADli7tSBXxx49SgGcF/;20:LYvww+cGmWltyPAuTV4E5BErLn5nFYQ77lCUoA1Y6a+ouGe7eOm+fbJVInA0XPjzGO9OGsuMqi9MPMJZBkQ2FTryqvk334znD6L3GyuU8XFBK2pHqApNK5Lv2fFXfK51rwNIR2ABuR1AVduripbU/SlGhkXuAl5Mk+ByS69TEB0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2016 08:47:58.6598 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB0582 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 30, 2016 at 09:07:05AM +0200, Michal Hocko wrote: > On Fri 27-05-16 19:18:21, Vladimir Davydov wrote: > > On Fri, May 27, 2016 at 01:18:03PM +0200, Michal Hocko wrote: > > ... > > > @@ -1087,7 +1105,25 @@ static int __set_oom_adj(struct file *file, int oom_adj, bool legacy) > > > unlock_task_sighand(task, &flags); > > > err_put_task: > > > put_task_struct(task); > > > + > > > + if (mm) { > > > + struct task_struct *p; > > > + > > > + rcu_read_lock(); > > > + for_each_process(p) { > > > + task_lock(p); > > > + if (!p->vfork_done && process_shares_mm(p, mm)) { > > > + p->signal->oom_score_adj = oom_adj; > > > + if (!legacy && has_capability_noaudit(current, CAP_SYS_RESOURCE)) > > > + p->signal->oom_score_adj_min = (short)oom_adj; > > > + } > > > + task_unlock(p); > > > > I.e. you write to /proc/pid1/oom_score_adj and get > > /proc/pid2/oom_score_adj updated if pid1 and pid2 share mm? > > IMO that looks unexpected from userspace pov. > > How much different it is from threads in the same thread group? > Processes sharing the mm without signals is a rather weird threading > model isn't it? I think so too. I wouldn't be surprised if it turned out that nobody had ever used it. But may be there's someone out there who does. > Currently we just lie to users about their oom_score_adj > in this weird corner case. Hmm, looks like a bug, but nobody has ever complained about it. > The only exception was OOM_SCORE_ADJ_MIN > where we really didn't kill the task but all other values are simply > ignored in practice. > > > May be, we'd better add mm->oom_score_adj and set it to the min > > signal->oom_score_adj over all processes sharing it? This would > > require iterating over all processes every time oom_score_adj gets > > updated, but that's a slow path. > > Not sure I understand. So you would prefer that mm->oom_score_adj might > disagree with p->signal->oom_score_adj? No, I wouldn't. I'd rather agree that oom_score_adj should be per mm, because we choose the victim basing solely on mm stats. What I mean is we don't touch p->signal->oom_score_adj of other tasks sharing mm, but instead store minimal oom_score_adj over all tasks sharing mm in the mm_struct whenever a task's oom_score_adj is modified. And use mm->oom_score_adj instead of signal->oom_score_adj in oom killer code. This would save us from any accusations of user API modifications and it would also make the oom code a bit easier to follow IMHO.