From: Matt Helsley <matthltc@us.ibm.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Jes Sorensen <jes@sgi.com>,
LSE-Tech <lse-tech@lists.sourceforge.net>,
Chandra S Seetharaman <sekharan@us.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
John T Kohl <jtk@us.ibm.com>, Balbir Singh <balbir@in.ibm.com>,
Shailabh Nagar <nagar@watson.ibm.com>,
CKRM-Tech <ckrm-tech@lists.sourceforge.net>
Subject: Re: [PATCH] Per-task watchers: Enable inheritance
Date: Wed, 21 Jun 2006 14:27:57 -0700 [thread overview]
Message-ID: <1150925277.21787.1053.camel@stark> (raw)
In-Reply-To: <44991FB3.4060209@bigpond.net.au>
On Wed, 2006-06-21 at 20:30 +1000, Peter Williams wrote:
> Matt Helsley wrote:
> > This allows per-task watchers to implement inheritance of the same function
> > and/or data in response to the initialization of new tasks. A watcher might
> > implement inheritance using the following notifier_call snippet:
> >
> > int my_notify_func(struct notifier_block *nb, unsigned long val, void *t)
> > {
> > struct task_struct *tsk = t;
> > struct notifier_block *child_nb;
> >
> > switch(get_watch_event(val)){
> > case WATCH_TASK_INIT: /* use container_of() to associate extra data */
> > child_nb = kzalloc(sizeof(struct notifier_block), GFP_KERNEL);
> > if (!child_nb)
> > return NOTIFY_DONE;
> > child_nb->notifier_call = my_notify_func;
> > register_per_task_watcher(tsk, child_nb);
> > return NOTIFY_OK;
> > case WATCH_TASK_FREE:
> > unregister_per_task_watcher(tsk, nb);
> > kfree(nb);
> > return NOTIFY_OK;
> >
> > Compile tested only. Peter, is this useful to you?
>
> I think that it's what I want (i.e. the implementation is what I would
> have done) but I'm confused by you reference to inheritance. My concern
> is to NOT inherit the data (via the notifier_block) but to have separate
> data for each task which is why I was concerned about not finding where
> "notify" was being initialized on boot.
Sorry, "inheritance" isn't exactly what it is. Poor choice of wording on
my part.
> What I'm doing is using an ordinary watcher to catch new tasks being
> created via WATCH_TASK_INIT and attaching a per task watcher to them at
> that time. As per your suggestion the notifier_block for the per task
> watcher is contained in a struct which contains the data that I need to
> maintain for each task. So two layers of watchers :-)
Hmm. Ideally you should need only one layer. When caps have been
established on a group you'd need to create the per-task watchers. From
there on I'd expect new tasks that fork to be added to the same group
using existing per-task watchers. Of course the trick is getting the
initial task(s) into the group. With per-task watchers that's difficult
because the group assignment might originate externally but registration
must happen from the context of the task being registered. I could
remove this restriction by paying an increased cost in complexity.
Please let me know if you run into extreme difficulties with per-task
watchers due to this context constraint.
> It will be a good test of your mechanism if I can get it to work.
Yes.
> It'll probably take me another couple of days to complete this code as
> I'm having to figure out how it all hangs together as I go. I'll let
> you know when I've finished.
>
> Peter
Thanks, I look forward to seeing it. Partially as a test and partially
because I'm curious if it will be compatible with the resource groups
(formerly CKRM) group structure.
Cheers,
-Matt Helsley
next prev parent reply other threads:[~2006-06-21 21:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 8:47 [PATCH] Per-task watchers: Enable inheritance Matt Helsley
2006-06-21 10:30 ` Peter Williams
2006-06-21 21:27 ` Matt Helsley [this message]
2006-06-23 21:17 ` John T. Kohl
2006-06-23 23:33 ` Matt Helsley
2006-06-24 0:08 ` Peter Williams
2006-06-26 13:03 ` John T. Kohl
2006-06-26 13:27 ` Peter Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1150925277.21787.1053.camel@stark \
--to=matthltc@us.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=jes@sgi.com \
--cc=jtk@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=nagar@watson.ibm.com \
--cc=pwil3058@bigpond.net.au \
--cc=sekharan@us.ibm.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox