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
| ||
|
Date: Thu, 18 Feb 2016 18:21:45 +0800 From: Xishi Qiu <qiuxishi@...wei.com> To: "Figo.zhang" <figo1802@...il.com>, David Rientjes <rientjes@...gle.com> CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, <arve@...roid.com>, <riandrews@...roid.com>, <devel@...verdev.osuosl.org>, zhong jiang <zhongjiang@...wei.com>, LKML <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org> Subject: Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan() On 2016/2/18 15:55, Figo.zhang wrote: > > > 2016-02-17 8:35 GMT+08:00 David Rientjes <rientjes@...gle.com <mailto:rientjes@...gle.com>>: > > 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)) > > > >
Powered by blists - more mailing lists