mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Keith Owens <kaos@sgi.com>
To: "Jan Beulich" <jbeulich@novell.com>
Cc: anil.s.keshavamurthy@intel.com, "Andrew Morton" <akpm@osdl.org>,
	"Andreas Kleen" <ak@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: notify_page_fault_chain
Date: Tue, 08 Aug 2006 14:05:17 +1000	[thread overview]
Message-ID: <8456.1155009917@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Mon, 07 Aug 2006 14:22:54 +0100." <44D75ACE.76E4.0078.0@novell.com>

"Jan Beulich" (on Mon, 07 Aug 2006 14:22:54 +0100) wrote:
>All,
>
>I just noticed this addition to i386 and x86-64, conditionalized upon CONFIG_KPROBES. May I ask what the motivation for
>this compatibility breaking change is? Only performance? I consider it already questionable to split out a specific
>fault from the general die notification (previous users of the functionality all of the sudden won't get notifications
>for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without CONFIG_KPROBES,
>and even with it not getting exported) is really odd.

Running all callbacks on the notify_die chain for every page fault was
causing a significant slowdown on large machines, especially when the
callback chain included heartbeat monitors, kernel debuggers and cross
partition NUMA access routines.

Only kprobes needs to know about page faults, none of the other
callbacks care about page faults.  So the notify_page_fault_chain chain
was added just for kprobes use, and made conditional on CONFIG_KPROBES.
That way only kprobed systems need to suffer the slowdown in page
faulting.


      parent reply	other threads:[~2006-08-08  4:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-07 13:22 notify_page_fault_chain Jan Beulich
2006-08-07 13:36 ` notify_page_fault_chain Andi Kleen
2006-08-07 14:50   ` notify_page_fault_chain Jan Beulich
2006-08-07 14:55     ` notify_page_fault_chain Andi Kleen
2006-08-08  4:05 ` Keith Owens [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=8456.1155009917@kao2.melbourne.sgi.com \
    --to=kaos@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.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

Powered by JetHome