Re: PHP performance on Xen domU with mulitple vcpu

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 18 May 2025 18:49:51 +0000
> From: Emmanuel Dreyfus <manu%netbsd.org@localhost>
> 
> On Sun, May 18, 2025 at 12:29:51PM +0000, Taylor R Campbell wrote:
> > And, if you built a kernel with options KDTRACE_HOOKS, can you share
> > any output from the following dtrace script?  (Will only print output
> > when something bad happens.)
> 
> I built with KDTRACE_HOOKS, but dtrace still does not work. It fails
> to load the dtrace module. Console says:
> [ 8928.7630011] kobj_checksyms, 1013: [dtrace]: linker error: symbol `dtrace_smap_enable' not found
> [ 8928.7630011] kobj_checksyms, 1013: [dtrace]: linker error: symbol `dtrace_smap_disable' not found
> [ 8928.7630011] WARNING: module error: Unable to affix module `dtrace', error 8

Please build with KDTRACE_HOOKS _and_ the patch I already sent you for
this, which I haven't committed yet because I was waiting for your
feedback on verifying it:

https://mail-index.NetBSD.org/tech-kern/2025/04/06/msg030329.html

> Perhaps we could just try a bunch of printfs?

You can try defining XEN_CLOCK_DEBUG in xen_clock.c, but:

1. you have to rebuild your kernel every time you want to change this,
   whereas with dtrace you can gather vast swaths of information
   flexibly without rebuilding your kernel or even rebooting; and

2. I seem to recall reports that the printfs are so noisy on some
   machines that they overwhelm the serial console and make the system
   hang at boot.

So it is absolutely worth the trouble to get dtrace working _now_ so
that you can repeatedly use it for many future diagnostics.