From: Benjamin LaHaise <bcrl@kvack.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@osdl.org>,
Chandra Seetharaman <sekharan@us.ibm.com>,
Keith Owens <kaos@sgi.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/8] Notifier chain update
Date: Wed, 18 Jan 2006 17:15:25 -0500 [thread overview]
Message-ID: <20060118221525.GI16285@kvack.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0601181706210.14089-100000@iolanthe.rowland.org>
On Wed, Jan 18, 2006 at 05:09:10PM -0500, Alan Stern wrote:
> On Wed, 18 Jan 2006, Benjamin LaHaise wrote:
>
> > The notifier interface is supposed to be *light weight*.
>
> Again, where is that documented?
Read the kernel. Notifiers are called from all sorts of hot paths, so they
damned well better be light.
> Which is worse: overhead due to cache misses or an oops caused by code
> being called after it was unloaded?
Given that the overhead need not be present at all, neither.
> Do you have a better proposal for a way to prevent blocking notifier
> chains from being modified while in use? Or would you prefer to rewrite
> all the callout routines that currently block, so that all the notifier
> chains can be made atomic and we don't need the blocking notifier API?
Easy: in register_notifier stuff a serial number for each entry put on
a notifier chain. Remember the serial number of the entry before performing
->notifier_call in notifier_call_chain. Upon return, if the chain has been
modified (easy to detect by nature of the serial number changing), walk
the chain looking for the entry following the last serial number run. Voila,
rcu can be used to protect the chain's contents.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@kvack.org>.
next prev parent reply other threads:[~2006-01-18 22:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 16:34 [PATCH 1/8] Notifier chain update Alan Stern
2006-01-18 18:19 ` Benjamin LaHaise
2006-01-18 20:23 ` Alan Stern
2006-01-18 21:42 ` Benjamin LaHaise
2006-01-18 21:57 ` Alan Stern
2006-01-18 22:00 ` David S. Miller
2006-01-18 22:04 ` Alan Stern
2006-01-18 23:06 ` Alan Cox
2006-01-19 3:33 ` Alan Stern
2006-01-18 22:01 ` Benjamin LaHaise
2006-01-18 22:09 ` Alan Stern
2006-01-18 22:15 ` Benjamin LaHaise [this message]
2006-01-19 10:01 ` Jes Sorensen
2006-01-18 22:18 ` David S. Miller
2006-01-18 22:18 ` Benjamin LaHaise
2006-01-18 23:07 ` Alan Cox
2006-01-19 9:55 ` Jes Sorensen
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=20060118221525.GI16285@kvack.org \
--to=bcrl@kvack.org \
--cc=akpm@osdl.org \
--cc=kaos@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--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.