On 02/28/2012 09:24 PM, Suleiman Souhlal wrote:

On Tue, Feb 28, 2012 at 11:00 AM, Glauber Costa[off-list ref]  wrote:

quoted

On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:

quoted

A later patch will also use this to move the accounting to the root
cgroup.

Suleiman,

Did you do any measurements to figure out how long does it take, average,
for dangling caches to go away ? Under memory pressure, let's say

Unfortunately, I don't have any such measurements, other than a very artificial:

# mkdir /dev/cgroup/memory/c
# echo 1073741824>  /dev/cgroup/memory/c/memory.limit_in_bytes
# sync&&  echo 3>  /proc/sys/vm/drop_caches
# echo $$>  /dev/cgroup/memory/c/tasks
# find />  /dev/null
# grep '(c)' /proc/slabinfo | wc -l
42
# echo $$>  /dev/cgroup/memory/tasks
# rmdir /dev/cgroup/memory/c
# grep '(c)dead' /proc/slabinfo | wc -l
42
# sleep 60&&  sync&&  for i in `seq 1 1000`; do echo 3>
/proc/sys/vm/drop_caches ; done
# grep '(c)dead' /proc/slabinfo | wc -l
6
# sleep 60&&  grep '(c)dead' /proc/slabinfo | wc -l
5
# sleep 60&&  grep '(c)dead' /proc/slabinfo | wc -l
5

(Note that this is without any per-memcg shrinking patch applied. With
shrinking, things will be a bit better, because deleting the cgroup
will force the dentries to get shrunk.)

Some of these dead caches may take a long time to go away, but we
haven't found them to be a problem for us, so far.

Ok. When we start doing shrinking, however, I'd like to see a shrink 
step being done before we destroy the memcg. This way we can at least 
reduce the number of pages lying around.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>