On Sat, Oct 08, 2005 at 01:58:38PM -0700, Paul Jackson wrote:
> Erik wrote:
> > This means that a given kernel module can only be added to the notifier list
> > of "current" or a child-in-construction.
>
> Just brainstorming here, but perhaps one could provide a simple
> mechanism that would allow one task to add to another's notifier
> list, without adding locks on the critical notifier structures.
Good idea. I think something like that could work. It keeps both
features that we need (or might need, we still need to know if we
loose any significant capability in "job" if we lose the ability
to attach/detach an arbitrary task to a job).
If "job" or any other PAGG user needs the this, I think it could
be done.
>
> Something like this. Add a lock managed list "task_notifier_join" to
> the task struct holding "requests to join a notifier list".
>
> When one task A wants to have another task B add notifier N, then A
> puts a request to join N on the task_notifier_join list of task B.
> During fork, exec and exit, task B notices that its task_notifier_join
> pointer is not empty, pulls off any requests to join from that list and
> signs up for the requested notifiers.
>
> This keeps all the performance critical notifier apparatus only
> useable in the context of the affected task, so its fast and lock
> free. It provides a second, slower, locked channel for sending
> requests to join a notifier from one task to another. That the
> request to join is asynchronous (the sender never knows when the
> receiver will get around to handling it) is ok. There are only a
> few events (such as fork, exec and exit) that might have notifier
> requests pending for, and the receiver will get around to handling
> the notifier join request the next time it gets to one of these
> events. That's plenty soon enough.
>
> Actually, I might like to pass more than join requests by such a
> mechanism. I'd like a way that one task could tell another that
> it has been moved to a different node, so needs to update its
> dplace state. Dplace is one of the mechanisms that uses this
> notifier, to find out about forks, execs and exits, so it can
> place the memory of new tasks on the right nodes. So in addition to
> sending a message from one task to another, telling it to sign up for a
> notifier, I'd also like to be able to send a notification from
> one task to the notifiers of another task, also to be delivered
> the next time the target task handled a fork, exec or exit event.
>
> I should change this lists name, from task_notifier_join, to
> something like telegram. Yeah - nice name.
>
> struct task_struct {
> ...
> struct list_head telegrams; /* inter-task messages */
>
> This gives us two, parallel kinds of notification:
> notifiers - from a task to a loadable module
> telegrams - from one task to another
>
> Both are processed only upon certain major life events of a task,
> such as fork, exec and exit.
>
> --
> I won't rest till it's the best ...
> Programmer, Linux Scalability
> Paul Jackson <pj@xxxxxxx> 1.925.600.0401
--
Thanks
Jack Steiner (steiner@xxxxxxx) 651-683-5302
Principal Engineer SGI - Silicon Graphics, Inc.
|