Messages in this thread | | | Date | Tue, 15 Nov 2005 14:17:39 -0500 | From | Hubertus Franke <> | Subject | Re: [RFC] [PATCH 00/13] Introduce task_pid api |
| |
Serge E. Hallyn wrote: > Quoting Paul Jackson (pj@sgi.com): > >>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 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/
| |