Thread (12 messages) 12 messages, 4 authors, 2012-03-16

Re: [RFC REPOST] cgroup: removing css reference drain wait during cgroup removal

From: KAMEZAWA Hiroyuki <hidden>
Date: 2012-03-14 00:30:10
Also in: linux-mm, lkml

On Tue, 13 Mar 2012 09:39:14 -0700
Tejun Heo [off-list ref] wrote:
Hello, KAMEZAWA.

On Tue, Mar 13, 2012 at 03:11:48PM +0900, KAMEZAWA Hiroyuki wrote:
quoted
The trouble for pre_destroy() is _not_ refcount, Memory cgroup has its own refcnt
and use it internally. The problem is 'charges'. It's not related to refcnt.
Hmmm.... yeah, I'm not familiar with memcg internals at all.  For
blkcg, refcnt matters but if it doesn't for memcg, great.
quoted
Cgroup is designed to exists with 'tasks'. But memory may not be related to any
task...just related to a cgroup.

But ok, pre_destory() & rmdir() is complicated, I agree.

Now, we prevent rmdir() if we can't move charges to its parent. If pre_destory()
shouldn't fail, I can think of some alternatives.

 * move all charges to the parent and if it fails...move all charges to
   root cgroup.
   (drop_from_memory may not work well in swapless system.)
I think this one is better and this shouldn't fail if hierarchical
mode is in use, right?
Right.

quoted
I think.. if pre_destory() never fails, we don't need pre_destroy().
For memcg maybe, blkcg still needs it.
quoted
quoted
  The last one seems more tricky.  On destruction of cgroup, the
  charges are transferred to its parent and the parent may not have
  enough room for that.  Greg told me that this should only be a
  problem for !hierarchical case.  I think this can be dealt with by
  dumping what's left over to root cgroup with a warning message.
I don't like warning ;) 
I agree this isn't perfect but then again failing rmdir isn't perfect
either and given that the condition can be wholly avoided in
hierarchical mode, which should be the default anyway (is there any
reason to keep flat mode except for backward compatibility?), I don't
think the trade off is too bad.
One reason is 'performance'. You can see performance trouble when you
creates deep tree of memcgs in hierarchy mode. The deeper memcg tree,
the more res_coutners will be shared.

For example, libvirt creates cgroup tree as

	/cgroup/memory/libvirt/qemu/GuestXXX/....
        /cgroup/memory/libvirt/lxc/GuestXXX/...

No one don't want to count up 4 res_coutner, which is very very heavy,
for handling independent workloads of "Guest".

IIUC, in general, even in the processes are in a tree, in major case
of servers, their workloads are independent.
I think FLAT mode is the dafault. 'heararchical' is a crazy thing which
cannot be managed.


Thanks,
-Kame

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help