On 2016/2/18 15:55, Figo.zhang wrote: > > > 2016-02-17 8:35 GMT+08:00 David Rientjes <rientjes@xxxxxxxxxx <mailto:rientjes@xxxxxxxxxx>>: > > On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote: > > > On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote: > > > Currently tasksize in lowmem_scan() only calculate rss, and not include swap. > > > But usually smart phones enable zram, so swap space actually use ram. > > > > Yes, but does that matter for this type of calculation? I need an ack > > from the android team before I could ever take such a core change to > > this code... > > > > The calculation proposed in this patch is the same as the generic oom > killer, it's an estimate of the amount of memory that will be freed if it > is killed and can exit. This is better than simply get_mm_rss(). > > However, I think we seriously need to re-consider the implementation of > the lowmem killer entirely. It currently abuses the use of TIF_MEMDIE, > which should ideally only be set for one thread on the system since it > allows unbounded access to global memory reserves. > > > > i don't understand why it need wait 1 second: > Hi David, How about kill more processes at one time? Usually loading camera will alloc 300-500M memory immediately, so call lmk repeatedly is a waste of time. And can we reclaim memory at one time instead of reclaim-alloc-reclaim-alloc... in this situation? e.g. use try_to_free_pages(), set nr_to_reclaim=300M Thanks, Xishi Qiu > if (test_tsk_thread_flag(p, TIF_MEMDIE) && > time_before_eq(jiffies, lowmem_deathpending_timeout)) { > task_unlock(p); > rcu_read_unlock(); > return 0; <= why return rather than continue? > } > > and it will retry and wait many CPU times if one task holding the TIF_MEMDI. > shrink_slab_node() > while() > shrinker->scan_objects(); > lowmem_scan() > if (test_tsk_thread_flag(p, TIF_MEMDIE) && > time_before_eq(jiffies, lowmem_deathpending_timeout)) > > > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
