On Thu, Apr 07, 2011 at 04:04:37PM -0400, Vivek Goyal wrote: > On Thu, Apr 07, 2011 at 09:08:04AM +1000, Dave Chinner wrote: > > [..] > > > At the very least, when a task is moved from one cgroup to another, > > > we've got a shared inode case. This probably won't happen more than > > > once for most tasks, but it will likely be common. > > > > That's not a shared case, that's a transfer of ownership. If the > > task changes groups, you have to charge all it's pages to the new > > group, right? Otherwise you've got a problem where a task that is > > not part of a specific cgroup is still somewhat controlled by it's > > previous cgroup. It would also still influence that previous group > > even though it's no longer a member. Not good for isolation purposes. > > > > And if you are transfering the state, moving the inode from the > > dirty list of one cgroup to another is trivial and avoids any need > > for the dirty state to be shared.... > > I am wondering how do you map a task to an inode. Multiple tasks in the > group might have written to same inode. Now which task owns it? That sounds like a completely broken configuration to me. If you are using cgroups for isolation, you simple do not share *anything* between them. Right now the only use case that has been presented for shared inodes is transfering a task from one cgroup to another. Why on earth would you do that if it is sharing resources with other tasks in the original cgroup? What use case does this represent, how often is it likely to happen, and who cares about it anyway? Let's not overly complicate things by making up requirements that nobody cares about.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
