lkml.org 
[lkml]   [2005]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH 00/13] Introduce task_pid api
    > But in the end isn't that more complicated than our approach?  The
    > kernel still needs to be modified to let processes request their pids,

    No - getpid() works, as always. Perhaps I don't understand your
    comment.


    > and now processes have to worry *always* about the value or range of
    > their pids, both at startup and restart.

    No - tasks get the pid the kernel gives them at fork, as always.
    The task keeps that exact same pid, across all checkpoints, restarts
    and migrations. Nothing that the application process has to worry
    about, either inside the kernel code or in userspace, beyond the fork
    code honoring the assigned pid range when allocating a new pid.

    No wide spread kernel code change, compared to yours. As now, tasks
    have a pid field, and that pid is the same value, system-wide.

    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.

    There will likely be other system-wide or job-wide name spaces and
    associated resources that will need to be preserved across these
    operations, such as shared memory, ipc, sockets, tmp files, signals,
    locking, shared file descriptors, process tree, permissions, ulimits,
    accounting, ... For each system-wide namespace, give each virtual
    server a dedicated portion of that space, the same across all servers
    in the farm. Where those names are kernel assigned, such as pids,
    teach the kernel to assign within the specified portion, such as the
    assigned pid range.

    The real complexity comes, I claim, from changing the pid from a
    system-wide name space to a partially per-job namespace. You can
    never do that conversion entirely and will always have confusions
    around the edges, as pids relative to one virtual server are used,
    incorrectly, in the environment of another virtual server or system
    wide.

    The difficulty of things is best not measured by the effort to
    do the first 90%, but by the effort to do the last 10%. And when
    trying to reconcile two irreconcilable concepts, that last 10% can
    never be completed.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@sgi.com> 1.925.600.0401
    -
    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/

    \
     
     \ /
      Last update: 2005-11-15 10:09    [W:3.008 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site