[Vserver] Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and Patches

From: Matt Helsley <matthltc_at_us.ibm.com>
Date: Fri 16 Dec 2005 - 02:20:52 GMT
Message-Id: <1134699652.10396.161.camel@stark>

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

_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Dec 16 02:29:21 2005

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 16 Dec 2005 - 02:29:26 GMT by hypermail 2.1.8