Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752587AbbEHF3e (ORCPT ); Fri, 8 May 2015 01:29:34 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:31747 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751795AbbEHF3a (ORCPT ); Fri, 8 May 2015 01:29:30 -0400 X-AuditID: cbfee691-f79ca6d00000456a-ca-554c49b841e0 Date: Fri, 08 May 2015 05:29:28 +0000 (GMT) From: Yogesh Narayan Gaur Subject: [EDT] oom_killer: find bulkiest task based on pss value To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, "ajeet.y@samsung.com" , amit.arora@samsung.com Reply-to: yn.gaur@samsung.com MIME-version: 1.0 X-MTR: 20150508050832444@yn.gaur Msgkey: 20150508050832444@yn.gaur X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-MLAttribute: X-RootMTR: 20150508050832444@yn.gaur X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N X-ConfirmMail: N,general Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 Message-id: <1803318889.244481431062967826.JavaMail.weblogic@epmlwas09d> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsWyRsSkTneHp0+owcKFchaXd81hc2D0+LxJ LoAxissmJTUnsyy1SN8ugStjb9c5toIO2Ypds+cyNTAukeli5OQQElCSmHr0AFsXIweHhICJ RNtEZpCwhICYxIV764HCXEAlSxkl5u05ywqRMJG40XiLCSIxh1Fiz/OvjCAJFgEViVsNU5lA bDYBA4ll3/6D2cICDhKf709mB2kQEZjKKPH8+llmiM2yEk/nPAGzeQUEJU7OfMICsUFBYum+ e6wQcUWJGfevM0HE5SSWTL0MZfNKzGh/ygITn/Z1DdTZ0hLnZ21ghHlh8ffHUHF+iWO3d0D1 CkhMPXMQqkZV4viGk1A2n8SahW9ZYOp3nVrODLPr/pa5UL0SEltbnoDdxgx025Tuh+wQtoHE kUVzWNH9wivgITHjxBxwMEoI/GWX+L9yDSsktAQkvk0+xDKBUXEWkp5ZSObOQjIXWc0CRpZV jKKpBckFxUnpRaZ6xYm5xaV56XrJ+bmbGIHJ4fS/ZxN3MN4/YH2IUYCDUYmH9wGrT6gQa2JZ cWXuIUZToNUTmaVEk/OBKSivJN7Q2MzIwtTE1NjI3NJMSZxXR/pnsJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGji2zpY/I9KcuS7qTxKvqc3OP0Dp29x9HP/z47Hkw6U65sbqb5tlF9Yfb emb+DKk2lP21xdZ4x4kdr1VMgp0+PNK6q1nLmtRxLN157v2NIioWZbWvJac8TZ9cHmmb0tEd 0bhYcElBy4ki7dTCpiNqFdfrjHIfRrM4fHRcms4ls4V3Z4Zzrq4SS3FGoqEWc1FxIgBT2a2d CQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsVy+t/tXt0dnj6hBu83iltc3jWHzYHR4/Mm uQDGqDSbjNTElNQihdS85PyUzLx0WyXv4HjneFMzA0NdQ0sLcyWFvMTcVFslF58AXbfMHKCh SgpliTmlQKGAxOJiJX07m6L80pJUhYz84hJbpWhDcyM9IwM9UyM9Q9NYK0MDAyNToJqEtIy9 XefYCjpkK3bNnsvUwLhEpouRk0NIQEli6tEDbCC2hICJxI3GW0wQtpjEhXvrgeJcQDVzGCX2 PP/KCJJgEVCRuNUwFayITcBAYtm3/2C2sICDxOf7k9lBGkQEpjJKPL9+lhlig6zE0zlPwGxe AUGJkzOfsEBsUJBYuu8eK0RcUWLG/etQm+Uklky9DGXzSsxof8oCE5/2dQ0zhC0tcX7WBkaY Sxd/fwwV55c4dnsHVK+AxNQzB6FqVCWObzgJZfNJrFn4lgWmftep5cwwu+5vmQvVKyGxteUJ 2G3MQLdN6X7IDmEbSBxZNIcV3S+8Ah4SM07MYZvAKDMLSWoWkvZZSNqR1SxgZFnFKJpakFxQ nJReYahXnJhbXJqXrpecn7uJEZxyni3cwfjlvPUhRgEORiUe3oesPqFCrIllxZW5hxglOJiV RHjN1YBCvCmJlVWpRfnxRaU5qcWHGE2BUTWRWUo0OR+YDvNK4g2NTcxNjU0tDAzNzc2UxHn/ n8sNERJITyxJzU5NLUgtgulj4uCUamA8mlm47UYH50e2qO9pYu6VRlWhzfsYVy5ZtNtnOsuB 0MzzggEXjcMvJvGEus6MzfggOLXYu4st7+SzjsD7HHWd8n+EJ7dZm6l5bDLalZXk+yVh6jJX hiU/tid8chEI3fl7iceC2cE7siSn+HXrZYqfWDhNfNvnY5NZPC+oOgXueT9jiRXf+n9KLMUZ iYZazEXFiQCBTpmxTwMAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t485TdQ3025978 Content-Length: 2840 Lines: 36 EP-2DAD0AFA905A4ACB804C4F82A001242F Hi Andrew, Presently in oom_kill.c we calculate badness score of the victim task as per the present RSS counter value of the task. RSS counter value for any task is usually '[Private (Dirty/Clean)] + [Shared (Dirty/Clean)]' of the task. We have encountered a situation where values for Private fields are less but value for Shared fields are more and hence make total RSS counter value large. Later on oom situation killing task with highest RSS value but as Private field values are not large hence memory gain after killing this process is not as per the expectation. For e.g. take below use-case scenario, in which 3 process are running in system. All these process done mmap for file exist in present directory and then copying data from this file to local allocated pointers in while(1) loop with some sleep. Out of 3 process, 2 process has mmaped file with MAP_SHARED setting and one has mapped file with MAP_PRIVATE setting. I have all 3 processes in background and checks RSS/PSS value from user space utility (utility over cat /proc/pid/smaps) Before OOM, below is the consumed memory status for these 3 process (all processes run with oom_score_adj = 0) ==================================================== Comm : 1prg, Pid : 213 (values in kB) Rss Shared Private Pss Process : 375764 194596 181168 278460 ==================================================== Comm : 3prg, Pid : 217 (values in kB) Rss Shared Private Pss Process : 305760 32 305728 305738 ==================================================== Comm : 2prg, Pid : 218 (values in kB) Rss Shared Private Pss Process : 389980 194596 195384 292676 ==================================================== Thus as per present code design, first it would select process [2prg : 218] as bulkiest process as its RSS value is highest to kill. But if we kill this process then only ~195MB would be free as compare to expected ~389MB. Thus identifying the task based on RSS value is not accurate design and killing that identified process didn?t release expected memory back to system. We need to calculate victim task based on PSS instead of RSS as PSS value calculates as PSS value = [Private (Dirty/Clean)] + [Shared (Dirty/Clean) / no. of shared task] For above use-case scenario also, it can be checked that process [3prg : 217] is having largest PSS value and by killing this process we can gain maximum memory (~305MB) as compare to killing process identified based on RSS value. -- Regards, Yogesh Gaur.????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?