Re: [PATCH v1 0/3] per-process reclaim

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 2016/6/13 19:50, Chen Feng 写道:
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 <angwoo2.park@xxxxxxx>
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?


Thanks.

Yes, In Huawei device, we use the interface now! Now according to procsss LRU state in ActivityManagerService, we can reclaim some process
in proactive way.


Cc: Redmond <u93410091@xxxxxxxxx>
Cc: ZhaoJunmin Zhao(Junmin) <zhaojunmin@xxxxxxxxxx>
Cc: Vinayak Menon <vinmenon@xxxxxxxxxxxxxx>
Cc: Juneho Choi <juno.choi@xxxxxxx>
Cc: Sangwoo Park <sangwoo2.park@xxxxxxx>
Cc: Chan Gyun Jeong <chan.jeong@xxxxxxx>

Minchan Kim (3):
   mm: vmscan: refactoring force_reclaim
   mm: vmscan: shrink_page_list with multiple zones
   mm: per-process reclaim

  Documentation/filesystems/proc.txt |  15 ++++
  fs/proc/base.c                     |   1 +
  fs/proc/internal.h                 |   1 +
  fs/proc/task_mmu.c                 | 149 +++++++++++++++++++++++++++++++++++++
  include/linux/rmap.h               |   4 +
  mm/vmscan.c                        |  85 ++++++++++++++++-----
  6 files changed, 235 insertions(+), 20 deletions(-)



.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]