All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.