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

[Serge E. Hallyn]

Quoting Paul Jackson (pj@xxxxxxx):
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/