Thread (7 messages) 7 messages, 3 authors, 2017-02-21

Re: Query on per app memory cgroup

From: Bob Liu <hidden>
Date: 2017-02-20 12:29:10

On Mon, Feb 20, 2017 at 1:22 PM, Vinayak Menon [off-list ref] wrote:

On 2/17/2017 6:47 PM, Bob Liu wrote:
quoted
On Thu, Feb 9, 2017 at 7:16 PM, Vinayak Menon [off-list ref] wrote:
quoted
Hi,

We were trying to implement the per app memory cgroup that Johannes
suggested (https://lkml.org/lkml/2014/12/19/358) and later discussed during
Minchan's proposal of per process reclaim
(https://lkml.org/lkml/2016/6/13/570). The test was done on Android target
with 2GB of RAM and cgroupv1. The first test done was to just create per
app cgroups without modifying any cgroup controls. 2 kinds of tests were
done which gives similar kind of observation. One was to just open
applications in sequence and repeat this N times (20 apps, so around 20
memcgs max at a time). Another test was to create around 20 cgroups and
perform a make (not kernel, another less heavy source) in each of them.

It is observed that because of the creation of memcgs per app, the per
memcg LRU size is so low and results in kswapd priority drop. This results
How did you confirm that? Traced the get_scan_count() function?
You may hack this function for more verification.
This was confirmed by adding some VM event counters in get_scan_count.
Would you mind attach your modification?
That would be helpful for people to make fix patches.

--
Thanks,
Bob

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help