Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2006-02-03 at 17:02 +0300, Alexey Kuznetsov wrote:
> 1. Replacing all the references to pid with pair (container, pid) is quite
> expensive. F.e. it is possible that a task has a pid from one container,
> but it is in process group and/or session of another container,
> and its controlling terminal owner by another container. Grr..
> So, the structures are bloated, the functions get additional arguments.
> And all this is for no real purpose, the functionality comparing with
> VPID is even reduced. 

I don't think anything gets bloated, at least in the default case.
Every task points to one and only one container.  Things that currently
take tasks as arguments still take tasks.  If something handling tasks
suddenly needs to worry about containers as well, we simply infer the
container from the task.

In the very, very rare cases where we can't do that (like a fork()
boundary), we _do_ change the APIs to take both task and container.
However, these are few and far between, so it isn't that much of a
headache.

In the cases where pids were referenced, and are no longer unique, we
use Eric's weak task references.  Right?

-- Dave

-
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]
  Powered by Linux