Hi, > -----Original Message----- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Tuesday, July 07, 2015 7:08 AM > To: PINTU KUMAR > Cc: cor...@lwn.net; a...@linux-foundation.org; vba...@suse.cz; > gorcu...@openvz.org; mho...@suse.cz; emun...@akamai.com; > kirill.shute...@linux.intel.com; standby2...@gmail.com; > han...@cmpxchg.org; vdavy...@parallels.com; hu...@google.com; > minc...@kernel.org; t...@kernel.org; rient...@google.com; > xypron.g...@gmx.de; dzic...@redhat.com; pra...@redhat.com; > ebied...@xmission.com; rost...@goodmis.org; uober...@redhat.com; > paul...@linux.vnet.ibm.com; iamjoonsoo....@lge.com; ddstr...@ieee.org; > sasha.le...@oracle.com; koc...@gmail.com; mgor...@suse.de; c...@linux.com; > opensource.gan...@gmail.com; vinme...@codeaurora.org; linux- > d...@vger.kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; linux- > p...@vger.kernel.org; c...@samsung.com; pintu_agar...@yahoo.com; > vishnu...@samsung.com; rohit...@samsung.com; iqbal....@samsung.com > Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory > feature > > On 2015/7/6 22:03, PINTU KUMAR wrote: > > > Hi, > > > >> -----Original Message----- > >> From: Xishi Qiu [mailto:qiuxi...@huawei.com] > >> Sent: Monday, July 06, 2015 3:53 PM > >> To: Pintu Kumar > >> Cc: cor...@lwn.net; a...@linux-foundation.org; vba...@suse.cz; > >> gorcu...@openvz.org; mho...@suse.cz; emun...@akamai.com; > >> kirill.shute...@linux.intel.com; standby2...@gmail.com; > >> han...@cmpxchg.org; vdavy...@parallels.com; hu...@google.com; > >> minc...@kernel.org; t...@kernel.org; rient...@google.com; > >> xypron.g...@gmx.de; dzic...@redhat.com; pra...@redhat.com; > >> ebied...@xmission.com; rost...@goodmis.org; uober...@redhat.com; > >> paul...@linux.vnet.ibm.com; iamjoonsoo....@lge.com; > >> ddstr...@ieee.org; sasha.le...@oracle.com; koc...@gmail.com; > >> mgor...@suse.de; c...@linux.com; opensource.gan...@gmail.com; > >> vinme...@codeaurora.org; linux- d...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; linux...@kvack.org; linux- > >> p...@vger.kernel.org; c...@samsung.com; pintu_agar...@yahoo.com; > >> vishnu...@samsung.com; rohit...@samsung.com; iqbal....@samsung.com > >> Subject: Re: [PATCH 1/1] kernel/sysctl.c: Add > >> /proc/sys/vm/shrink_memory feature > >> > >> On 2015/7/3 21:20, Pintu Kumar wrote: > >> > >>> This patch provides 2 things: > >>> 1. Add new control called shrink_memory in /proc/sys/vm/. > >>> This control can be used to aggressively reclaim memory system-wide > >>> in one shot from the user space. A value of 1 will instruct the > >>> kernel to reclaim as much as totalram_pages in the system. > >>> Example: echo 1 > /proc/sys/vm/shrink_memory > >>> > >>> 2. Enable shrink_all_memory API in kernel with new > >> CONFIG_SHRINK_MEMORY. > >>> Currently, shrink_all_memory function is used only during hibernation. > >>> With the new config we can make use of this API for non-hibernation > >>> case also without disturbing the hibernation case. > >>> > >>> The detailed paper was presented in Embedded Linux Conference, > >>> Mar-2015 > >>> http://events.linuxfoundation.org/sites/events/files/slides/ > >>> %5BELC-2015%5D-System-wide-Memory-Defragmenter.pdf > >>> > >>> Scenarios were this can be used and helpful are: > >>> 1) Can be invoked just after system boot-up is finished. > >>> 2) Can be invoked just before entering entire system suspend. > >>> 3) Can be invoked from kernel when order-4 pages starts failing. > >>> 4) Can be helpful to completely avoid or delay the kerenl OOM condition. > >>> 5) Can be developed as a system-tool to quickly defragment entire system > >>> from user space, without the need to kill any application. > >>> > >> > >> Hi Pintu, > >> > >> How about increase min_free_kbytes and Android lowmemorykiller's level? > >> > > Thanks for the review. > > Actually in Tizen, we don't use Android LMK and we wanted to delay the > > LMK with aggressive direct_reclaim offline. > > And increasing min_free value also may not help much. > > Currently, in our case free memory never falls below 10MB, with 512MB > > RAM configuration. > > > > How about the performance as you reclaim so much memory? > (e.g. shrink page cache, use zram, ksm, compaction...) When launching the same > app next time, it may be slow, right? > Yes, obviously, there will be slight degrade in performance for relaunch of application. But, it will be better that the first launch. Please check the following data: Browser Launch: 01-01 12:06:26.550 01-01 12:06:28.340 Time taken: 1790 ms
Relaunch: 01-01 12:09:08.130 01-01 12:09:08.380 Time: 250ms After shrink_memory again: 01-01 12:12:17.280 01-01 12:12:17.770 Time: 490ms The main point here is that the killing is avoided and application data is retained. Also, when the memory pressure situation arises leading to slowpath again and again, We will be already in the performance degraded state. Instead of continuous performance degradation, a one time is better. > How about use cgroup to manage the apps, but I don't know how to do the > detail. > Yes, we already use cgroups, vmpressure, to manage memory threshold for reclaim, swap and kill. Even cgroup also have a similar force_reclaim mechanism, to reclaim pages within groups for a particular threshold. But, that is at a later stages and also it does not care about order of the pages. It does not perform system-wide reclaim. > Thanks, > Xishi Qiu > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
