答复: [PATCH 4.3-rc6] proc: fix oom_adj value read from /proc/<pid>/oom_adj

["Hongjie Fang (方洪杰)" <Hongjie.Fang@spreadtrum.com>]

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@xmission.com>
发送时间: 2015年10月21日 1:27
收件人: Hongjie Fang (方洪杰)
抄送: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org; Andrew Morton; linux-mm@kvack.org
主题: Re: [PATCH 4.3-rc6] proc: fix oom_adj value read from /proc/<pid>/oom_adj

"Hongjie Fang (方洪杰)" <Hongjie.Fang@spreadtrum.com> 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@spreadtrum.com>
> ---
> 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)) {
>
> --