Re: ia64_do_page_fault shows 19.4% slowdown from notify_die.

Keshavamurthy Anil S
2006-04-18T23:05:54Z

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