public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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