Re: [RFC][PATCH 0/5] memcg softlimit (Another one) v4

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2009-03-12 09:52:47]:

> Hi, this is a patch for implemnt softlimit to memcg.
> 
> I did some clean up and bug fixes. 
> 
> Anyway I have to look into details of "LRU scan algorithm" after this.
> 
> How this works:
> 
>  (1) Set softlimit threshold to memcg.
>      #echo 400M > /cgroups/my_group/memory.softlimit_in_bytes.
> 
>  (2) Define priority as victim.
>      #echo 3 > /cgroups/my_group/memory.softlimit_priority.
>      0 is the lowest, 8 is the highest.
>      If "8", softlimit feature ignore this group.
>      default value is "8".
> 
>  (3) Add some memory pressure and make kswapd() work.
>      kswapd will reclaim memory from victims paying regard to priority.
> 
> Simple test on my 2cpu 86-64 box with 1.6Gbytes of memory (...vmware)
> 
>   While a process malloc 800MB of memory and touch it and sleep in a group,
>   run kernel make -j 16 under a victim cgroup with softlimit=300M, priority=3.
> 
>   Without softlimit => 400MB of malloc'ed memory are swapped out.
>   With softlimit    =>  80MB of malloc'ed memory are swapped out. 
> 
> I think 80MB of swap is from direct memory reclaim path. And this
> seems not to be terrible result.
> 
> I'll do more test on other hosts. Any comments are welcome.

Hi, Kamezawa-San,

I tried some simple tests with this patch and the results are not
anywhere close to expected.

1. My setup is 4GB RAM with 4 CPUs and I boot with numa=fake=4
2. I setup my cgroups as follows
   a. created /a and /b and set memory.use_hierarchy=1
   b. created /a/x and /b/x, set their memory.softlimit_priority=1
   c. set softlimit_in_bytes for a/x to 1G and b/x to 2G
   d. I assigned tasks to a/x and b/x

I expected the tasks in a/x and b/x to get memory distributed in the
ratio to 1:2. Here is what I found

1. The task in a/x got more memory than the task in b/x even though
   I started the task in b/x first
2. Even changing softlimit_priority (increased for b) did not help much


-- 
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/