From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752683AbcFOAnb (ORCPT ); Tue, 14 Jun 2016 20:43:31 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:41055 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751894AbcFOAna (ORCPT ); Tue, 14 Jun 2016 20:43:30 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Wed, 15 Jun 2016 09:43:34 +0900 From: Minchan Kim To: Chen Feng Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Rik van Riel , Redmond , "ZhaoJunmin Zhao(Junmin)" , Vinayak Menon , Juneho Choi , Sangwoo Park , Chan Gyun Jeong Subject: Re: [PATCH v1 0/3] per-process reclaim Message-ID: <20160615004334.GB17127@bbox> References: <1465804259-29345-1-git-send-email-minchan@kernel.org> <575E9DE8.4050200@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <575E9DE8.4050200@hisilicon.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chen, On Mon, Jun 13, 2016 at 07:50:00PM +0800, Chen Feng wrote: > Hi Minchan, > > On 2016/6/13 15:50, Minchan Kim wrote: > > Hi all, > > > > http://thread.gmane.org/gmane.linux.kernel/1480728 > > > > I sent per-process reclaim patchset three years ago. Then, last > > feedback from akpm was that he want to know real usecase scenario. > > > > Since then, I got question from several embedded people of various > > company "why it's not merged into mainline" and heard they have used > > the feature as in-house patch and recenlty, I noticed android from > > Qualcomm started to use it. > > > > Of course, our product have used it and released it in real procuct. > > > > Quote from Sangwoo Park > > Thanks for the data, Sangwoo! > > " > > - Test scenaro > > - platform: android > > - target: MSM8952, 2G DDR, 16G eMMC > > - scenario > > retry app launch and Back Home with 16 apps and 16 turns > > (total app launch count is 256) > > - result: > > resume count | cold launching count > > ----------------------------------------------------------------- > > vanilla | 85 | 171 > > perproc reclaim | 184 | 72 > > " > > > > Higher resume count is better because cold launching needs loading > > lots of resource data which takes above 15 ~ 20 seconds for some > > games while successful resume just takes 1~5 second. > > > > As perproc reclaim way with new management policy, we could reduce > > cold launching a lot(i.e., 171-72) so that it reduces app startup > > a lot. > > > > Another useful function from this feature is to make swapout easily > > which is useful for testing swapout stress and workloads. > > > Thanks Minchan. > > Yes, this is useful interface when there are memory pressure and let the userspace(Android) > to pick process for reclaim. We also take there series into our platform. > > But I have a question on the reduce app startup time. Can you also share your > theory(management policy) on how can the app reduce it's startup time? What I meant about start-up time is as follows, If a app is killed, it should launch from start so if it was the game app, it should load lots of resource file which takes a long time. However, if the game was not killed, we can enjoy the game without cold start so it is very fast startup. Sorry for confusing.