Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Paul Jackson <pj@sgi.com>]

Serge wrote:
> Well a vserver pretends to be a full system of its own

Do you have any references, links?

> In fact this is one way we considered implementing the virtual pids -

No no - not what I meant.  I meant to have the pid be the same in all
views, for all time, kernel and user, inside and outside the virtual
server.  Just like pids are now.  A given virtual server would have
a dedicated range of pids, reserved for it on all hardware systems
in the farm.

You could move the tasks in one such virtual server from one hardware
system to another without having pid collisions because the destination
hardware system would have been reserving those pids all along for
that virtual server.

The additional kernel facilities this would require:
 1) For a given task (inherited) designate which pid range to use for
    newly forked children.
 2) Restart a task into the same pid it had before, which would fail
    if that pid was in use by any other task on the system.

Administratively, create named virtual servers, each one assigned
a permanent pid range.  On each hardware system, each task would
be managed to be using pids for forking from the pid range for the
virtual server it was running in.

Perhaps each hardware system would have one pid range, say pids
0..2000, overlapping with all other such systems, for tasks specific
to that hardware system.  These tasks could not be checkpoint/restarted
on another hardware system.

For example, the virtual server "magnolia" would always have pids
9,000 to 9,999, and all hardware systems in the server farm would
keep this pid range open for running "magnolia", if asked to.  If you
saw a tasks pid was 9.543, then you would immediately know it ran
on virtual server "magnolia."

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401