Quoting Paul Menage ([EMAIL PROTECTED]): > On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote: > > > >All that being said, if it were going to save space without overly > >complicating things I'm actually not opposed to using nsproxy, but it > > If space-saving is the main issue, then the latest version of my
Space saving was the only reason for nsproxy to exist. Now of course it also provides the teensiest reduction in # instructions since every clone results in just one reference count inc for the nsproxy rather than one for each namespace. > containers patches uses just a single pointer in the task_struct, and > all tasks in the same set of containers (across all hierarchies) will > share a single container_group object, which holds the actual pointers > to container state. Yes, that's why this consolidation doesn't make sense to me. Especially considering again that we will now have nsproxies pointing to containers pointing to... nsproxies. > Effectively, container_group is to container as nsproxy is to namespace. > > Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
