From: Matt Helsley <matthltc@us.ibm.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>,
Shailabh Nagar <nagar@watson.ibm.com>,
Chandra S Seetharaman <sekharan@us.ibm.com>,
John T Kohl <jtk@us.ibm.com>, Balbir Singh <balbir@in.ibm.com>,
Jes Sorensen <jes@sgi.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
LSE-Tech <lse-tech@lists.sourceforge.net>
Subject: Re: [Lse-tech] [PATCH 00/11] Task watchers: Introduction
Date: Wed, 21 Jun 2006 22:37:00 -0700 [thread overview]
Message-ID: <1150954621.21787.1272.camel@stark> (raw)
In-Reply-To: <449A1C0D.7030906@bigpond.net.au>
On Thu, 2006-06-22 at 14:26 +1000, Peter Williams wrote:
<snip>
> >>>> BTW as a former user of PAGG, I think there are ideas in the PAGG
> >>>> implementation that you should look at. In particular:
> >>>>
> >>>> 1. The use of an array of function pointers (one for each hook) can cut
> >>>> down on the overhead. The notifier_block only needs to contain a
> >>>> pointer to the array so there's no increase in the size of that
> >>>> structure. Within the array a null pointer would mean "don't bother
> >>>> calling". Only one real array needs to exist even for per task as
> >>>> they're all using the same functions (just separate data). It removes
> >>>> the need for a switch statement in the client's function as well as
> >>>> saving on unnecessary function calls.
> >>> I don't think having an explicit array of function pointers is likely
> >>> to be as fast as a switch statement (or a simple branch) generated by
> >>> the compiler.
> >> With the array there's no need for any switch or branching. You know
> >> exactly which function in the array to use in each hook.
> >
> > I don't forsee enough of a difference to make this worth arguing about.
> > You're welcome to benchmark and compare arrays vs. switches/branches on
> > a variety of archs, SMP boxen, NUMA boxen, etc. and post the results.
> > I'm going to focus on other issues for now.
> >
> >>> It doesn't save unecessary function calls unless I modify the core
> >>> notifier block structure. Otherwise I still need to stuff a generic
> >>> function into .notifier_call and from there get the pointer to the array
> >>> to make the next call. So it adds more pointer indirection but does not
> >>> reduce the number of intermediate function calls.
> >> There comes a point when trying to reuse existing code is less cost
> >> effective than starting over.
> >
> > Write my own notifier chains just to avoid a function call? I don't
> > think that's sufficient justification for implementing my own.
>
> Can't help thinking why the easier option of adding setuid and setgid
> hooks to PAGG and then including PAGG wasn't adopted.
Task watchers is not intended to group tasks. It's intended to factor a
common pattern out of these paths in a way useful to existing parts of
the kernel, proposed changes, and modules.
Your goal of grouping tasks seems like it could use task watchers. That
does not mean that every task watcher needs to manage groups of tasks.
Cheers,
-Matt Helsley
next prev parent reply other threads:[~2006-06-22 5:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-13 23:52 [PATCH 00/11] Task watchers: Introduction Matt Helsley
2006-06-19 10:24 ` Andrew Morton
2006-06-21 8:35 ` Matt Helsley
2006-06-21 9:07 ` Andrew Morton
2006-06-21 9:13 ` [Lse-tech] " Matt Helsley
2006-06-21 10:40 ` Peter Williams
2006-06-21 21:32 ` Matt Helsley
2006-06-21 5:41 ` Peter Williams
2006-06-21 7:51 ` Matt Helsley
2006-06-21 11:34 ` Peter Williams
2006-06-21 11:41 ` Peter Williams
2006-06-21 21:29 ` Matt Helsley
2006-06-21 23:04 ` Peter Williams
2006-06-22 0:32 ` Matt Helsley
2006-06-22 1:11 ` Peter Williams
2006-06-22 3:46 ` Matt Helsley
2006-06-22 4:26 ` Peter Williams
2006-06-22 5:37 ` Matt Helsley [this message]
2006-06-22 6:29 ` [Lse-tech] " Peter Williams
2006-06-22 19:53 ` Chandra Seetharaman
2006-06-22 22:46 ` 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=1150954621.21787.1272.camel@stark \
--to=matthltc@us.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--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