On Thu, Aug 30, 2012 at 5:34 PM, Nishanth Peethambaran
Thanks Nishanth for careful review.
nishanth.peethu@gmail.com wrote:
ion_buffer_create is called with dev->lock acquired and so dev->lock would have to be freed and schedule out before retry so that the process getting killed can free up all the memory. Else, it will get blocked while freeing the first buffer in ion_buffer_destroy() when it tries to acquire the dev->lock.
Your concern is correct. My mistake for considering no problem if debugfs test no problem. Will resend the updated the patch, 1. move ion_shrink out of mutex. 2. check error flag of ERR_PTR(-ENOMEM) 3. add msleep to allow schedule out.
debugfs of carveout_heap might show the client not using the heap though memory is not freed. If the buffer was mapped to userspace, ion_share_dma_buf() would have taken one reference of ion_buffer() So, all the ion_buffer_put() will succeed if dma_buf fd is not released first and thus all the ion_handle_put() will succeed and will remove the handles from the client before ion_client_destroy() will try to acquire dev->lock()
Sorry, not fully understand. The ion_shrink will send_sig according to used size, is this solve your concern.
A lowmem killer with multiple threshold, omm_adj values similar to android lowmem killer would be also an option but it is a matter of policy whether each carveout/cma heap needs to do a lowmem killer or not. For some cases, fallback to other heaps would be ok and for some cases fallback to other heaps like kmalloc and vmalloc or even other carveout/cma areas might not be an option.
This simple killer is refer lownmemorykiller. It is useful for us, since we still not enable CMA.
Is there any particular reason to use send_sig() and set_tsk_thread_flag() instead of force_sig(). Just curious to know.
This staff is referring lowmemorykiller.c set_tsk_thread_flag is required no matter use send_sig() or force_sig(). However, during stress testing, force_sig() may cause system NULL pointer error. While send_sig() is much stable.
Besides, the stress test on non android system, is manually ion_shrink(heap, -1). While usually ion_shrink(heap, 0), without kill adj <= 0.
- Nishanth Peethambaran
On Wed, Aug 29, 2012 at 10:50 AM, Haojian Zhuang haojian.zhuang@gmail.com wrote:
On Wed, Aug 29, 2012 at 11:52 AM, Zhangfei Gao zhangfei.gao@marvell.com wrote:
ion_shrink is called when ION_CARVEOUT_ALLOCATE_FAIL
How to test: mount -t debugfs none /mnt cat /mnt/ion/carveout_heap echo adj > /mnt/ion/carveout_heap send_sig SIGKILL to the task with higher adj and using ion buffer Also kill all others tasks refered the buffers, in case using empty buffer
Example:
cat /mnt/ion/carveout_heap client pid size oom_score_adj ion_test 191 4096 0 ion_test 192 4096 0 ion_test 193 4096 0
echo -1 > /mnt/ion/carveout_heap [ 1333.689318] SIGKILL pid: 191 [ 1333.692192] SIGKILL pid: 192 [ 1333.695436] SIGKILL pid: 193 [ 1333.698312] SIGKILL pid: 193 size: 4096 adj: 0 [1]+ Killed ./ion_test 2
cat /mnt/ion/carveout_heap client pid size oom_score_adj
Signed-off-by: Zhangfei Gao zhangfei.gao@marvell.com
Although it's good for keeping ION can always allocating memory, I doubt this killer won't be merged in android kernel mainline.
Nobody care OOM killer on ION since CMA heap may be used in the future. Although fragment also exists in CMA heap, the solution is used to declare a larger CMA area.
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig