The oom_adj has been replaced by oom_score_adj in kernel,
but the /proc/<pid>/oom_adj is provided for legacy purposes.
When write/read value into/from /proc/<pid>/oom_adj,
there is a transformation between oom_adj
and oom_score_adj in oom_adj_write()/oom_adj_read().
After writing a new value into /proc/<pid>/oom_adj, then read it.
The return value is different with what has been written.
As the flowing:
1. #cat /proc/1386/oom_adj
-15
2. # echo -14 > /proc/1386/oom_adj
3. # cat /proc/1386/oom_adj
-13
This patch is to fix it.
The patch effect on oom_score_adj value is small and smooth,
also little impact on oom_killer.
unpatch oom_adj->oom_score_adj->oom_adj:
-17->-1000->-17
-16->-941->-15
-15->-882->-14
-14->-823->-13
-13->-764->-12
-12->-705->-11
-11->-647->-10
-10->-588->-9
-9->-529->-8
-8->-470->-7
-7->-411->-6
-6->-352->-5
-5->-294->-4
-4->-235->-3
-3->-176->-2
-2->-117->-1
-1->-58->0
0->0->0
1->58->0
2->117->1
3->176->2
4->235->3
5->294->4
6->352->5
7->411->6
8->470->7
9->529->8
10->588->9
11->647->10
12->705->11
13->764->12
14->823->13
15->1000->17
patched oom_adj->oom_score_adj->oom_adj:
-17->-1000->-17
-16->-942->-16
-15->-883->-15
-14->-824->-14
-13->-765->-13
-12->-706->-12
-11->-648->-11
-10->-589->-10
-9->-530->-9
-8->-471->-8
-7->-412->-7
-6->-353->-6
-5->-295->-5
-4->-236->-4
-3->-177->-3
-2->-118->-2
-1->-59->-1
0->0->0
1->59->1
2->118->2
3->177->3
4->236->4
5->295->5
6->353->6
7->412->7
8->471->8
9->530->9
10->589->10
11->648->11
12->706->12
13->765->13
14->824->14
15->1000->17
Hongjie
________________________________________
发件人: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
发送时间: 2015年10月21日 1:27
收件人: Hongjie Fang (方洪杰)
抄送: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Andrew Morton; linux-mm@xxxxxxxxx
主题: Re: [PATCH 4.3-rc6] proc: fix oom_adj value read from /proc/<pid>/oom_adj
"Hongjie Fang (方洪杰)" <Hongjie.Fang@xxxxxxxxxxxxxx> writes:
> The oom_adj's value reading through /proc/<pid>/oom_adj is different
> with the value written into /proc/<pid>/oom_adj.
> Fix this by adding a adjustment factor.
*Scratches my head*
Won't changing the interpretation of what is written break existing
userspace applications that write this value?
Added a few more likely memory management suspects that might understand
what is going on here.
Eric
>
> Signed-off-by: Hongjie Fang <hongjie.fang@xxxxxxxxxxxxxx>
> ---
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b25eee4..1ea0589 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1043,6 +1043,7 @@ static ssize_t oom_adj_write(struct file *file, const char __user *buf,
> int oom_adj;
> unsigned long flags;
> int err;
> + int adjust;
>
> memset(buffer, 0, sizeof(buffer));
> if (count > sizeof(buffer) - 1)
> @@ -1084,8 +1085,10 @@ static ssize_t oom_adj_write(struct file *file, const char __user *buf,
> */
> if (oom_adj == OOM_ADJUST_MAX)
> oom_adj = OOM_SCORE_ADJ_MAX;
> - else
> - oom_adj = (oom_adj * OOM_SCORE_ADJ_MAX) / -OOM_DISABLE;
> + else{
> + adjust = oom_adj > 0 ? (-OOM_DISABLE-1) : -(-OOM_DISABLE-1);
> + oom_adj = (oom_adj * OOM_SCORE_ADJ_MAX + adjust) / -OOM_DISABLE;
> + }
>
> if (oom_adj < task->signal->oom_score_adj &&
> !capable(CAP_SYS_RESOURCE)) {
>
> --?韬{.n???檩jg???a?旃???)钋???骅w+h?璀?ｙ/i?⒏??⒎???Щ ??m?? ?)钋???痂?^??觥??ザ?v???O璁?f??i?⒏?