[Devel] Re: [PATCH v5 1/3] cgroups: read-write lock CLONE_THREAD forking per threadgroup
On Tue, Aug 10, 2010 at 10:47 PM, Ben Blum wrote: > > > Adds functionality to read/write lock CLONE_THREAD fork()ing per-threadgroup > > From: Ben Blum > > This patch adds an rwsem that lives in a threadgroup's signal_struct that's > taken for reading in the fork path, under CONFIG_CGROUPS. If another part of > the kernel later wants to use such a locking mechanism, the CONFIG_CGROUPS > ifdefs should be changed to a higher-up flag that CGROUPS and the other system > would both depend on. > > This is a pre-patch for cgroup-procs-write.patch. > > Signed-off-by: Ben Blum Acked-by: Paul Menage Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v5 2/3] cgroups: add can_attach callback for checking all threads in a group
On Tue, Aug 10, 2010 at 10:48 PM, Ben Blum wrote: > > Add cgroup wrapper for safely calling can_attach on all threads in a > threadgroup > > From: Ben Blum > > This patch adds a function cgroup_can_attach_per_thread which handles > iterating > over each thread in a threadgroup safely with respect to the invariants that > will be used in cgroup_attach_proc. Also, subsystems whose can_attach calls > require per-thread validation are modified to use the per_thread wrapper to > avoid duplicating cgroup-internal code. > > This is a pre-patch for cgroup-procs-writable.patch. > > Signed-off-by: Ben Blum Acked-by: Paul Menage Some of the can_attach() methods could be simplified slightly by directly returning the result of cgroup_can_attach_per_thread() Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] unshare pidns and setns syscall
Hi Eric, do you plan to send a new version of the 'setns' patchset ? I will be happy to test it if you have a more recent one. In the meantime, we kept porting your patchset on top of the latest kernels. http://lxc.sourceforge.net/patches/linux/2.6.35/2.6.35-lxc1/patches/ Thanks -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
Re: [Devel] Re: Containers vs. OpenVZ
On 08/23/2010 01:08 PM, Peter Volkov wrote: > В Пнд, 23/08/2010 в 11:44 +0400, Pavel Emelyanov пишет: >> And no - you cannot replace openvz with lxc yet for many reasons. > > Pavel, I think lot's of people will benefit if you summarize important > points of differences. Yea, I have my own list but I'd better listen to > knowledgeable people first ;) :) OK, but first of all - the list I provide is just the situation we currently have that will change in the future, not some fundamental problem. Besides, I can be not aware of some recent changes, so please correct me if I'm wrong. So, the benefits of the OpenVZ against LXC. 1. Checkpointing. That's the biggest difference. 2. Resource management. Currently in LCX you may only have a per container user memory management. In OpenVZ we control much more resources like kernel memory or networking buffers 3. Entering a container. I've seen many approaches of how to join a foreign container (sys_hijack, sys_nsfd, sys_cloneat, etc) but AFAIK none of them is included in the mainline. 4. 2-level disk quota. We're trying to push one into the Al's tree however ;) 5. Bells-and-whistles like NFS/NFSd virtualization, FUSE virtualization, etc 6. Containers management like vzlist tool or various /proc files, that help you to track containers state and resources > With best regards, ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
Re: [Devel] Re: Containers vs. OpenVZ
В Пнд, 23/08/2010 в 11:44 +0400, Pavel Emelyanov пишет: > And no - you cannot replace openvz with lxc yet for many reasons. Pavel, I think lot's of people will benefit if you summarize important points of differences. Yea, I have my own list but I'd better listen to knowledgeable people first ;) With best regards, -- Peter. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: Containers vs. OpenVZ
> Marc, > > We are quite aware of and appreciate openvz's many kernel > contributions. Please consider the context of Oren's reply above. I was > talking about checkpoint/restart not being in the mainline kernel. I > am not aware of any openvz checkpoint/restart code in the mainline > kernel. [ Cc'ing Pavel so he can correct me if I am wrong. ] No we don't have any our cpt/rst code in the mainline unfortunately :( And no - you cannot replace openvz with lxc yet for many reasons. > Cheers, > -Matt Helsley > ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
