At Sat, 5 Apr 2025 07:09:09 +0000, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote: Subject: Re: PHP performance on Xen domU with mulitple vcpu > > On Fri, Apr 04, 2025 at 05:27:49PM -0700, Greg A. Woods wrote: > > So which Xen kernel version is this with? > > My bet is that it's newer than 4.11. > > Indeed, this is 4.3.1 I'm not sure I understand that number. Do you mean this one? https://xenproject.org/blog/announcing-the-release-of-xen-project-4-3-1/ If so then that's a really really old version! To confirm, what does "xl info" in the dom0 show? In particular the xen_version line. I actually have no problems with 4.13 (nor did I with 4.11), but 4.18 an early pre-release of 4.20-rc were all failing. (I've never tried 4.15) > > Also which exact CPU model is your system using? > > cpu0: "Intel(R) Xeon(R) CPU E3-1220 v6 @ 3.00GHz" That's even one year newer than the system with E5645's I have that works A-OK with Xen 4.18 The CPUs I've had problems with are from 2007. (X5460 and E5440). > > It is interesting that setting kern.timecounter.hardware=clockinterrupt > > is enough to work around the ntpd problem -- I'll try that for the > > similar problems I've been having with Xen kernels >= 4.18. > > Well, no, it happens with clockinterrupt, not with xen_system_time. > But with xen_system_time, ntpd is unable to keep in sync. That's what I meant -- that with clockinterrupt then ntpd is able to keep the system wallclock time in sync vs. falling out of sync when using xen_system_time. I'd never tried changing the kern.timecounter though I did consider trying to use either "ichlpcib0" or "ACPI-Safe" in the dom0 (but those are difficult to use in dom0), so I find it fascinating that using the worst possible quality one (other than "dummy") does something that enables ntpd to keep time. One other question I forgot to ask: With xen_system_time does timekeeping work OK for the first few days and then go bad, or is it bad right from boot? My problematic systems work perfectly for the first ~7.5 days, then quickly degrade. In any case I don't believe this is a problem in NetBSD -- but rather a bug in the Xen kernel that's exacerbated on certain CPUs -- probably something to do with its emulation of TSC vs. how well the TSC works in the hardware. I've mentioned this problem to the Xen developers and Andrew Cooper's response was "Time handling is a known swamp." -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpEpMFO0Iq4I.pgp
Description: OpenPGP Digital Signature