linux-kernel - Re: [EDT] oom_killer: find bulkiest task based on pss value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFP4FLppUwsmWw=B5VDkE7UgRe118DifH9U5Y1sM_TJag8WxgA@mail.gmail.com>
Date:	Fri, 8 May 2015 15:47:24 +0800
From:	yalin wang <yalin.wang2010@...il.com>
To:	yn.gaur@...sung.com
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	"ajeet.y@...sung.com" <ajeet.y@...sung.com>, amit.arora@...sung.com
Subject: Re: [EDT] oom_killer: find bulkiest task based on pss value

2015-05-08 13:29 GMT+08:00 Yogesh Narayan Gaur <yn.gaur@...sung.com>:
>
> 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.


Great,

in fact, i also encounter this scenario,
i use USS (page map counter == 1) pages
to decide which process should be killed,
seems have the same result as you use PSS,
but PSS is better , it also consider shared pages,
in case some process have large shared pages mapping
but little Private page mapping

BRs,
Yalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/