lkml.org 
[lkml]   [2006]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (pspace,pid) vs true pid virtualization
Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>
>>"Serge E. Hallyn" <serue@us.ibm.com> writes:
>>With respect to pids lets not get caught up in the implementation
>>details. Let's first get clear on what the semantics should be.
>>
>>- Should the first pid in a pid space have pid 1?
that should only be required if you have system containers
or if there are tools or requirements that if I wonderup my process tree
that I ultimately must end up at 1.
>>
>>- Should pid == 1 ignore signals, it doesn't have a handler for?

Yes
>>
>>- Should any children of pid 1 be allowed to live when pid == 1 is killed?
No .. it has init semantics !

>
>
> But doesn't that depend on whether we use (pspace,pid) or vpids? If
> vpids, then init isn't really a problem, since from kernelspace
> processes in a comtainer stil have a global pid and global parent, and
> init knows them. If (pspace,pid), then we need a fakeinit bc the real
> init doesn't know about the processes in the container...
>
>
>>- Should a process have some sort of global (on the machine identifier)?

First establish whether that global ID has to be persistent ...
I don't see why ! In which case the TASK_REF is the perfect global ID.
>
>
> I think to satisfy openvz existing customers this must be a yes. With
> vpid the answer is simple. With (pspace,pid), there are three anwers i've
> heard, namely
>
> 1. just use pspaceid, pid
> 2. make pspaceid small and use (pspaceid << SOMEBITS | pid)
> 3. use pid1/pid2/pid3 where pid1 is creator of pid and its
> pspace, etc...
This implies that pid2 can be looked up in the context of pid1.
In OpenVZ approach that's possible, In pspaces.. isn't that the wpid ?

>
> But the openvz guys also don't want userspace tool changes, making (2)
> the most likely option. Any other ideas?
>
>
>>- Should the pids in a pid space be visible from the outside?
>
>
> Again, the openvz guys say yes.
>
> I think it should be acceptable if a pidspace is visible in all it's
> ancestor pidspaces. I.e. if I create pspace2 and pspace3 from pid 234
> in pspace1, then pspace2 doesn't need to be able to address pspace3
> and vice versa.

That means you need to do a more complicated lookup ! for instance let's say you have hierarchy
pspace1
|--->pspace2
| |--->pspace2a
|--->pspace3
|--->pspace3a

let's assume we use the (pspaceid<<BITS | pid ) global id. To verify I have to
ensure that the target pid can reach the originating pid in its ancestor path.
Not a biggy as these pspace trees probably won't get much deeper then 3 or 4.

>
> Kirill, is that acceptable?
>
>
>>- Should the parent of pid 1 be able to wait for it for it's
>> children?
>
> Yes.

Yes ... VPID does that and wpid in pspace does that as well.
>
>
>>- Is a completely disjoin pid space acceptable to anyone?
>
>
> To anyone? yes :)
>
> TO everyone, I don't think so.
>
hehh... yes they should be disjoined other then at the top
where we want to wait ..
>
>>- What should the parent of pid == 1 see?
>>
>>- Should a process not in the default pid space be able to create
>> another pid space?
>
>
> Yes.

How else do you get hierarchy ....

>
> This is to support using pidspaces for vservers, and creating
> migrateable sub-pidspaces in each vserver.
>
>
>>- Should we be able to monitor a pid space from the outside?
>
>
> To some extent, yes.
>
>
>>- Should we be able to have processes enter a pid space?
>
>
> IMO that is crucial.

Existing ones .. now that is potentially difficult to do. Particular
if you want to enter a pidspace that has already been migrated.
Because ones assigned pid might already been taken in the target pspace.

>
>
>>- Do we need to be able to be able to ptrace/kill individual processes
>> in a pid space, from the outside, and why?
>
>
> I think this is completely unnecessary so long as a process can enter a
> pidspace.
>
>
>>- After migration what identifiers should the tasks have?
>
>
> It must be possible to retain the same pids, at least from inside the
> container.

Absolutely .. otherwise all cashed pids in userspace are meaningless.

>
> So this is irrelevant, as the openvz approach can just virtualize the
> old pid, while (pspace, pid) will be able to create a new container and
> use the old pid values, which are then guaranteed to not be in use.

Exactly .. mute issue, this is "trivial" as long as you can fork with
a particular pid used.

>
>
>>If we can answer these kinds of questions we can likely focus in
>>on what the implementation should look like. So far I have not
>>seen a question that could not be implemented with a (pspace, pid)/pid
>>or a vpid/pid implementation.
>
>
> But you have, haven't you? Namely, how can openvz provide it's
> customers with a global view of all processes without putting 5 years of
> work into a new sysadmin interface?
>
> -serge
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-17 04:39    [W:0.372 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site