Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH] clocksource: disable irq when holding watchdog_lock. | Date | Thu, 19 Oct 2023 14:14:34 +0200 |
| |
On Thu, Oct 19 2023 at 18:30, Tetsuo Handa wrote: > On 2023/10/17 23:10, Paul E. McKenney wrote: >>> But I'm hitting something different (but might be timer/scheduler related) problem. >>> What config option would cause taking more than 2 minutes to bring up only 8 CPUs? >>> (This environment is Oracle VM VirtualBox on Windows 11 host.) >>> >> The timing is about the same in both cases. Does this happen in kernels >> built with CONFIG_PROVE_LOCKING=n? > > Disabling all options in "Lock Debugging (spinlocks, mutexes, etc...)" does not help. > >> >> Either way, what mainline or -stable version is this? > > The kernel is latest commit of upstream linux.git tree. > I'm seeing this slowdown (almost hung-up) problem for many releases, > but nobody else seems to be reporting this problem.
Maybe because of this: >>> (This environment is Oracle VM VirtualBox on Windows 11 host.)
> The only reliable workaround is to specify "nosmp" kernel command line option.
Which makes the kernel keep TSC as clocksource because there is no synchronization problem between CPU0 and CPU0 :)
What is the fallback clocksource when the TSC is discarded on SMP?
From the dmesg snippets I assume it is the ACPI PMTIMER, which is I/O port based and presumably takes a VMEXIT on every read and depending on the emulation this might be slooooow.
So you could boot with "nosmp clocksource=acpi_pm" on the command line and compare that against a "nosmp" boot.
If my assumption is right, then on UP the ACPI PM variant won't see the massive slowdown SMP observes, but there should be still an observable difference.
Thanks,
tglx
| |