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.
I guess the one thing I really don't see supported here (apart from the
system/laptop joins the network after spawning a job which has been
mentioned) is restarting multiple simulatenous instances of a single
checkpoint. In the pidspace approach, each restarted instance would
have a different pidspace id, but use the same vpids. In the
preallocation scheme, only one pid has been reserved at checkpoint for
each process instance.
Is there a simple way to solve this? (And how valid a concern is
this? :)
Other than that, I guess your approach is growing on me...
-serge
-
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]
