linux-kernel - Re: [PATCH 3/3] staging: lowmemorykiller: select the task with maximum rss to kill

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160622044448.GC5683@leo-test>
Date:	Wed, 22 Jun 2016 12:44:48 +0800
From:	Ganesh Mahendran <opensource.ganesh@...il.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	gregkh@...uxfoundation.org, arve@...roid.com, riandrews@...roid.com
Subject: Re: [PATCH 3/3] staging: lowmemorykiller: select the task with
 maximum rss to kill

Hi, David:

On Tue, Jun 21, 2016 at 01:14:36PM -0700, David Rientjes wrote:
> On Tue, 21 Jun 2016, Ganesh Mahendran wrote:
> 
> > Current task selecting logic in LMK does not fully aware of the memory
> > pressure. It may select the task with maximum score adj, but with
> > least tasksize.
> > 
> > For example, if min_score_adj is 200, and there are 2 tasks in system:
> >    task a: score adj 500, tasksize 200M
> >    task b: score adj 1000, tasksize 1M
> > Current LMK logic will select *task b*. But now the system already have
> > much memory pressure.
> > 
> > We should select the task with maximum task from all the tasks which
> > score adj >= min_score_adj.
> > 
> 
> Unfortunately, I'm not sure that we can get away with this although I 
> agree that it is a better result (kill a large process, avoid lowmem or 
> oom for longer).

Yes, from our testing with this patch applied, system works more smoothly,
and user have better experience.

> 
> It changes the kill order for systems that have already fine-tuned their 
> oom_score_adj settings and can regress because of this change.  If systems 
> really want task b to be killed above, this breaks and they have no 
> immediate way of fixing it.

I think the processes with score_adj >= min_score_adj are all acceptable
if we kill them. In android products, LMK does the main job to free memory
when system is hard to shrink file/anon pages. If LMK does not free enough memory,
the system will be very slow before OOM is triggered. During this period, user will
have bad experience.

So LMK need to work effectivly to let system running smoothly, as user experience
is very important for android system.

Thanks.