From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org, Anton Blanchard <anton@samba.org>
Subject: Re: [patch 06/10] Add notify die hooks and remove some redundant debugger hooks
Date: Tue, 10 Apr 2007 10:19:22 +0530 [thread overview]
Message-ID: <20070410044922.GB15332@in.ibm.com> (raw)
In-Reply-To: <17946.5029.162940.708672@cargo.ozlabs.ibm.com>
On Mon, Apr 09, 2007 at 08:21:25PM +1000, Paul Mackerras wrote:
>
> The other thing is that we seem to be throwing all sorts of unrelated
> events into the die_notifier. The symptom of that is that you have
> one set of handlers that are only interested in the debug events, and
> another set that are only interested in the events where the machine
> really is dying (oops, etc.). That is, you have two sets of handlers
> that are interested in disjoint sets of events. That says to me that
> we shouldn't be using a single notifier for all the events.
> Particularly for page faults I really don't see the point of calling
> handlers that are only interested in oopses.
The page fault no longer uses the die_notifier. In recent kernels, we
have done away with registering the page fault notifier unconditionally.
In the kprobe case, its active only if there are any active probes.
As to the debug events vs. dying events both using the die_notifier, we
did it that way just to maintain consistency across platforms. i386,
x86_64 and sparc64 were using similar stuff before we put in the powerpc
portions.
Aside, I was told that some folks use the page fault notifiers to
determine application behaviour or somesuch and have used it effectively
to solve some of their performance issues. I don't have the details
though.
Ananth
next prev parent reply other threads:[~2007-04-10 4:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-21 1:38 [patch 00/10] Oops path and debugger hooks rework anton
2007-03-21 1:38 ` [patch 01/10] Add missing oops_enter/oops_exit anton
2007-03-21 1:38 ` [patch 02/10] Clean up pmac_backlight_unblank in oops path anton
2007-03-21 1:38 ` [patch 03/10] Handle recursive oopses anton
2007-03-21 1:38 ` [patch 04/10] Fix backwards ? : when printing machine type anton
2007-03-21 1:38 ` [patch 05/10] Use KERN_EMERG everywhere in oops printout anton
2007-03-21 2:23 ` Stephen Rothwell
2007-03-23 11:00 ` Paul Mackerras
2007-03-21 1:38 ` [patch 06/10] Add notify die hooks and remove some redundant debugger hooks anton
2007-03-21 16:14 ` Christoph Hellwig
2007-03-23 11:14 ` Paul Mackerras
2007-03-23 11:29 ` Christoph Hellwig
2007-03-23 12:04 ` Ananth N Mavinakayanahalli
2007-03-23 14:09 ` Anton Blanchard
2007-03-24 3:17 ` Paul Mackerras
2007-04-09 10:21 ` Paul Mackerras
2007-04-10 4:49 ` Ananth N Mavinakayanahalli [this message]
2007-03-21 1:38 ` [patch 07/10] Page fault handler should not depend on CONFIG_KPROBES anton
2007-03-21 16:13 ` Christoph Hellwig
2007-03-23 14:19 ` Anton Blanchard
2007-03-21 1:38 ` [patch 08/10] Use notifier hooks for xmon anton
2007-03-21 1:38 ` [patch 09/10] Use lowercase for hex printouts in oops messages anton
2007-03-21 2:14 ` Olof Johansson
2007-03-21 7:17 ` Geert Uytterhoeven
2007-03-21 16:44 ` Segher Boessenkool
2007-03-21 1:38 ` [patch 10/10] Make sure we only enable xmon once anton
2007-03-21 2:04 ` Anton Blanchard
2007-03-21 2:11 ` Olof Johansson
2007-03-21 2:05 ` Anton Blanchard
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=20070410044922.GB15332@in.ibm.com \
--to=ananth@in.ibm.com \
--cc=anton@samba.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/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;
as well as URLs for NNTP newsgroup(s).