On Thu, 2005-12-15 at 11:49 -0800, Gerrit Huizenga wrote:
> On Thu, 15 Dec 2005 09:35:57 EST, Hubertus Franke wrote:
> > This patchset is a followup to the posting by Serge.
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=113200410620972&w=2
> >
> > In this patchset here, we are providing the pid virtualization mentioned
> > in serge's posting.
> >
> > > I'm part of a project implementing checkpoint/restart processes.
> > > After a process or group of processes is checkpointed, killed, and
> > > restarted, the changing of pids could confuse them. There are many
> > > other such issues, but we wanted to start with pids.
> > >
> > > This patchset introduces functions to access task->pid and ->tgid,
> > > and updates ->pid accessors to use the functions. This is in
> > > preparation for a subsequent patchset which will separate the kernel
> > > and virtualized pidspaces. This will allow us to virtualize pids
> > > from users' pov, so that, for instance, a checkpointed set of
> > > processes could be restarted with particular pids. Even though their
> > > kernel pids may already be in use by new processes, the checkpointed
> > > processes can be started in a new user pidspace with their old
> > > virtual pid. This also gives vserver a simpler way to fake vserver
> > > init processes as pid 1. Note that this does not change the kernel's
> > > internal idea of pids, only what users see.
> > >
> > > The first 12 patches change all locations which access ->pid and
> > > ->tgid to use the inlined functions. The last patch actually
> > > introduces task_pid() and task_tgid(), and renames ->pid and ->tgid
> > > to __pid and __tgid to make sure any uncaught users error out.
> > >
> > > Does something like this, presumably after much working over, seem
> > > mergeable?
> >
> > These patches build on top of serge's posted patches (if necessary
> > we can repost them here).
> >
> > PID Virtualization is based on the concept of a container.
> > The ultimate goal is to checkpoint/restart containers.
> >
> > The mechanism to start a container
> > is to 'echo "container_name" > /proc/container' which creates a new
> > container and associates the calling process with it. All subsequently
> > forked tasks then belong to that container.
> > There is a separate pid space associated with each container.
> > Only processes/task belonging to the same container "see" each other.
> > The exception is an implied default system container that has
> > a global view.
<snip>
> I think perhaps this could also be the basis for a CKRM "class"
> grouping as well. Rather than maintaining an independent class
> affiliation for tasks, why not have a class devolve (evolve?) into
> a "container" as described here. The container provides much of
> the same grouping capabilities as a class as far as I can see. The
> right information would be availble for scheduling and IO resource
> management. The memory component of CKRM is perhaps a bit tricky
> still, but an overall strategy (can I use that word here? ;-) might
> be to use these "containers" as the single intrinsic grouping mechanism
> for vserver, openvz, application checkpoint/restart, resource
> management, and possibly others?
>
> Opinions, especially from the CKRM folks? This might even be useful
> to the PAGG folks as a grouping mechanism, similar to their jobs or
> containers.
>
> "This patchset solves multiple problems".
>
> gerrit
CKRM classes seem too different from containers to merge the two
concepts:
- Classes don't assign class-unique pids to tasks.
- Tasks can move between classes.
- Tasks move between classes without any need for checkpoint/restart.
- Classes show up in a filesystem interface rather that using a file
in /proc to create them. (trivial interface difference)
- There are no "visibility boundaries" to enforce between tasks in
different classes.
- Classes are hierarchial.
- Unless I am mistaken, a container groups processes (Can one thread run
in container A and another in container B?) while a class groups tasks.
Since a task represents a thread or a process one thread could be in
class A and another in class B.
Cheers,
-Matt Helsley
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
