Hello, On Fri, Jul 22, 2011 at 05:25:58PM -0700, Matt Helsley wrote: > Finally, I think there's substantial room here for quiet and subtle > races to corrupt checkpoint images. If we add /proc interfaces only to > find they're racy will we need to add yet more /proc interfaces to > maintain backward compatibility yet fix the races? To get the locking > that ensures a consistent subset of information with this /proc-based > approach I think we'll frequently need to change the contents of > existing /proc files. The target processes need to be frozen to remove race conditions (be it SIGSOTP, cgroup freeze or PTRACE trap). If there are exceptions in the boundaries between frozen domain and the rest of the system, they'll need to be dealt with and those need to be dealt with whether the thing is in kernel or not. > Imagine trusting the output of top to exactly represent the state of > your system's cpu usage. That's the sort of thing a piecemeal /proc > interface gets us. You're asking us to trust that frequent checkpoints > (say once every five minutes) of large, multiprocess, month-long > program runs won't quietly get corrupted and will leave plenty of > performance to not interfere with the throughput of the work. This is rather bogus. If you freeze the processes, most of the information in /proc (the ones which would show up in top anyway) doesn't change. What race condition? > A kernel syscall interface has a better chance of allowing us to fix > races without changing the interface. We've fixed a few races with > Oren's tree and none of them required us to change the output format. Sure, that was completely embedded in the kernel and things can be implemented and fixed with much less consideration. I can see how that would be easier for the specific use case, but that EXACTLY is why it can't go upstream. I just can't see it happening and think it would be far more productive spending the time and energy looking for and implementing solutions which actually can go mainline. If you don't care about mainlining, that's great too, but then there's no point in talking about it either. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers