2014 09 24 23:36, Rik van Riel: > On 09/22/2014 10:57 PM, Hui Zhu wrote: >> The cause of this issue is when free memroy size is low and a lot of task is >> trying to shrink the memory, the task that is killed by lowmemkiller cannot get >> CPU to exit itself. >> >> Fix this issue with change the scheduling policy to SCHED_FIFO if a task's flag >> is TIF_MEMDIE in lowmemkiller. > > Is it actually true that the task that was killed by lowmemkiller > cannot get CPU time? I am so sorry that answer this mail late because I tried to do more test around it. But this issue is really hard to reproduce the issue. I got a special app that can reproduce this issue easyly. But I still need retry a lot of times to repdroduce this issue. And I found that most of time, the task cannot be killed because it is blocked by binder_lock. It looks like there are something wrong with a task that get binder_lock and it is blocked by another thing. So I make a patch that change a binder_lock to binder_lock_killable to handle this issue.(I will post it later) It work sometime but I am not sure it is right. And I just met one time, the kernel with the binder patch and without the lowmemkiller SCHED_FIFO patch, a task that didn't blocked by a lock. And different tasks call lowmemkiller tried to kill this task. I think the root cause of this issue is killed task cannot get cpu. But I just got this issue one time. > > It is also possible that the task is busy in the kernel, for example > in the reclaim code, and is not breaking out of some loop fast enough, > despite the TIF_MEMDIE flag being set. > > I suspect SCHED_FIFO simply papers over that kind of issue, by not > letting anything else run until the task is gone, instead of fixing > the root cause of the problem. > > According to I introduction, I think lowmemkiller SCHED_FIFO patch maybe can handle some issue. Thanks, Hui _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
