From: Chandra Seetharaman <sekharan@us.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Optimizing notifier_call_chain
Date: Wed, 23 Nov 2005 13:13:59 -0800 [thread overview]
Message-ID: <1132780439.6492.13.camel@linuxchandra> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0511231057430.4477-100000@iolanthe.rowland.org>
On Wed, 2005-11-23 at 11:01 -0500, Alan Stern wrote:
> On Tue, 22 Nov 2005, Chandra Seetharaman wrote:
>
> > Hello,
> >
> > While making the notifier chain safe, i found room for some optimization.
> > Please comment on if it is worth pursuing.
> >
> > notifier_call_chain() calls registered callouts for _all_ events. But, many
> > of the callouts handle only few events.
> >
> > If we change notifier_call_chain() to call the callout only on registered
> > events, we can avoid few function overhead.
> >
> > Currently, events is of free format, we have to make it bit per event.
> > Among the existing users, ia64die_chain uses the highest number(25) of
> > events. i think 64 bit event would suffice.
> >
> > simplified logic:
> > notifier_call_chain(event)
> > {
> > if ((head->event & event) != 0)
> > return;
> > for_each_callout {
> > if ((notifier_block->event & event) != 0)
> > notifier_block->call(event);
> > }
> > }
>
> You would need to mask against (1ull << event), not against event.
> tset_bit() might work better.
event will be a bit field, not a sequential number.
>
> Do you really want to do this? It will mean changing every single
> notifier_block definition in the kernel, in addition to all the the
> notifier_heads. That's an awful lot of work for a relatively small gain.
Valid question. That is one of the reason of my posting this question.
I was planning to make the interface change to handle bitwise events
with zero being "all events". Future users will use the bitwise events.
w.r.t existing users, i would change only the macros(that were listed)
and let the module owners do the change to the notifier blocks when they
want (or file a kernel janitor bug).
The object was to move towards optimization.
> I believe that notifier_call_chain does not run very often, but I don't
> have any actual figures.
>
> Alan Stern
>
>
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------
prev parent reply other threads:[~2005-11-23 21:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-23 3:27 Optimizing notifier_call_chain Chandra Seetharaman
2005-11-23 16:01 ` Alan Stern
2005-11-23 21:13 ` Chandra Seetharaman [this message]
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=1132780439.6492.13.camel@linuxchandra \
--to=sekharan@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--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.