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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
