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

[Minchan Kim]

On Mon, Jun 13, 2016 at 06:59:40PM +0530, Vinayak Menon wrote:
> On 6/13/2016 1:20 PM, 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.
> >
> Thanks Minchan for bringing this up. When we had tried the earlier patchset in its original form,
> the resume of the app that was reclaimed, was taking a lot of time. But from the data shown above it looks
> to be improving the resume time. Is that the resume time of "other" apps which were able to retain their working set
> because of the more efficient swapping of low priority apps with per process reclaim ?

Sorry for confusing. I meant the app should start from the scratch
if it was killed, which might need load a hundread megabytes while
resume needs to load just workingset memory which would be smaller.

> Because of the higher resume time we had to modify the logic a bit and device a way to pick a "set" of low priority
> (oom_score_adj) tasks and reclaim certain number of pages (only anon) from each of them (the number of pages reclaimed
> from each task being proportional to task size). This deviates from the original intention of the patch to rescue a
> particular app of interest, but still using the hints on working set provided by userspace and avoiding high resume stalls.
> The increased swapping was helping in maintaining a better memory state and lesser page cache reclaim,
> resulting in better app resume time, and lesser task kills.

Fair enough.

> 
> So would it be better if a userspace knob is provided to tell the kernel, the max number of pages to be reclaimed from a task ?
> This way userspace can make calculations depending on priority, task size etc and reclaim the required number of pages from
> each task, and thus avoid the resume stall because of reclaiming an entire task.
> 
> And also, would it be possible to implement the same using per task memcg by setting the limits and swappiness in such a
> way that it results inthe same thing that per process reclaim does ?

Yeb, I read Johannes's thread which suggests one-cgroup-per-app model.
It does make sense to me. It is worth to try although I guess it's not
easy to control memory usage on demand, not proactively.
If we can do, maybe we don't need per-process reclaim policy which
is rather coarse-grained model of reclaim POV.
However, a concern with one-cgroup-per-app model is LRU list size
of a cgroup is much smaller so how LRU aging works well and
LRU churing(e.g., compaction) effect would be severe than old.

I guess codeaurora tried memcg model for android.
Could you share if you know something?

Thanks.


> 
> Thanks,
> Vinayak