Serge E. Hallyn wrote:
Quoting Paul Jackson ([email protected]):
An additional per-task attribute, set by a batch manager typically
when it starts a job on a checkpointable, restartable, movable
"virtual server" connects the job parent task, and hence all its
descendents in that job, with a named kernel object that has among its
attributes a pid range. When fork is handing out new pids, it honors
that pid range. User level code, in the batch manager or system
administration layer manages a set of these named virtual servers,
including assigning pid ranges to them, and puts what is usually the
same such configuration on each server in the farm.
And that's how we implement this.
The difference is that the pidrange-id is assigned on the fly,
that is when the virtual server is created or recreated after restart.
This, as described in my previous note, is more scalable, because I don't have
to do a global pidrange partitioning.
global pidrange partitioning has implications, for instance what if I simply
want to freeze an app only to restart it much later. This would freeze that
range autmatically.
On process restart, we force fork to use a particular <pidspace/pid> for its
kernel pid assignment, rather then searching for a free one.
-- Hubertus
-
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]
