Re: ia64_do_page_fault shows 19.4% slowdown from notify_die.

[Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>]

On Tue, Apr 18, 2006 at 05:16:23PM -0500, Robin Holt wrote:
> On Tue, Apr 18, 2006 at 10:23:52AM +1000, Keith Owens wrote:
> > I thought that is what I said in my original response, "kprobes should
> 
> I was a little dense and had forgotten that KDB would still need to
> register as a debugger.
> 
> 
> Some micro-benchmarking has shown this to be very painful.  The average
> of 128 iterations with 4194304 faults per iteration using the attached
> micro-benchmark showed the following:
> 
> 499 nSec/fault ia64_do_page_fault notify_die commented out.
> 501 nSec/fault ia64_do_page_fault with nobody registered.
> 533 nSec/fault notify_die in and just kprobes.
> 596 nSec/fault notify_die in and kdb, kprobes, mca, and xpc loaded.
> 
> The 596 nSec/fault is a 19.4% slowdown.  This is an upcoming OSD beta
> kernel.  It will be representative of what our typical customer will
> have loaded.
> 
> Is this enough justification for breaking notify_die into
> notify_page_fault for the fault path?

Yes sir, I am convinced 100%.

> 
> 
> > that chain should be optimized away when CONFIG_KPROBES=n or there are
> > no active probes".
> 
> Having the notify_page_fault() without anybody registered was only a
> 0.4% slowdown.  I am not sure that justifies the optimize away, but I
> would certainly not object.
> 
> I think the second and third numbers also indicate strongly that kprobes
> should only be registering the notify_page_fault when it actually is
> monitoring for a memory access.  I know so little about how kprobes works,
> I will stop right there.  Is there anybody who is willing to take that
> task or explain why it is impossible?

I will take it up and submit a path soon.
Thanks for your analysis.

-Anil