Dave Hansen wrote: > On Wed, 2008-07-30 at 16:35 -0500, Serge E. Hallyn wrote: >> So task 5 created its mm_struct, task 6 is >> supposed to use the same mm_struct, so it finds that out from the >> context? I wonder whether that would start to become complicated >> when checkpointing nested containers. > > It also doesn't fit well with the nsproxy idea. It would be very hard > to tell which nsproxies should be shared until the entire restart has > been completed and we've been able to figure out which ones are the > same. I'm not sure I fully understand the problem that you describe, however, I reckon that nsproxies are, basically, yet-another shared object between tasks in the kernel. As such, the CR logic will treat them like other shared objects: the first time one is found, its state will be saved; the next time the same one is found, only an identifier will be saved. That definitely means that, yes, the state within nsproxies as kernel resources will have to be saved as part of the checkpoint. Oren. > > This is just a coding/implementation issue, but I think it does reveal a > difference in ideology between these patches and the way that the kernel > works up until now. :) > > -- Dave > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
