From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945943AbcBRKWi (ORCPT ); Thu, 18 Feb 2016 05:22:38 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:15097 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425530AbcBRKWL (ORCPT ); Thu, 18 Feb 2016 05:22:11 -0500 Message-ID: <56C59B39.30102@huawei.com> Date: Thu, 18 Feb 2016 18:21:45 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Figo.zhang" , David Rientjes CC: Greg Kroah-Hartman , , , , zhong jiang , LKML , Linux MM Subject: Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan() References: <56C2EDC1.2090509@huawei.com> <20160216173849.GA10487@kroah.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.56C59B4D.0085,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b848b24ef6e3f26c0969dd377d032625 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/2/18 15:55, Figo.zhang wrote: > > > 2016-02-17 8:35 GMT+08:00 David Rientjes >: > > 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)) > > > >