[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors
> > > Yes, and that is already done, hooked off the cpu notifier > > > callback chain. Nobbling the C- and P-state logic < shouldn't be necessary. > > > > And yet, people are still reporting "Time went backwards" > > messages upwards of 30-40 times an hour on RevF Opterons > > when PowerNow! is enabled on Xen. > > > > I spent a month trying to debug this and I made no significant > > progress. If someone who understands Xen timekeeping wants to > > help me dive into this, I'll be glad to take another stab at > > it. As it is, even with informing Xen of frequency changes, > > Xen does not ensure monotinicity. > > I do think we need to understand what's going on here. > > Are the 'time went backwards' messages correlated with power > management operations? Yes, I can regularly generate messages by switching the governor from powersave (minimum frequency) to performance (maximum frequency). > How far is time stepping backwards? > ns, us, or ms? Rolf's message is typical: > Jan 19 00:11:09 server kernel: printk: 14 messages suppressed. > Jan 19 00:11:09 server kernel: Timer ISR/0: Time went backwards: > delta=-123862858 delta_cpu=-123862858 shadow= > 2993571302800 off=705014593 processed=2994400167600 cpu_processed=2994400167600 > Jan 19 00:11:09 server kernel: 0: 2994400167600 > Jan 19 00:11:09 server kernel: 1: 2994213786880 > Jan 19 00:11:09 server kernel: Timer ISR/1: Time went backwards: > delta=-50043804 delta_cpu=136336916 shadow=29 > 93571302800 off=778821372 processed=2994400167600 cpu_processed=2994213786880 > Jan 19 00:11:09 server kernel: 0: 2994400167600 > Jan 19 00:11:09 server kernel: 1: 2994213786880 > Jan 19 00:11:09 server kernel: Timer ISR/1: Time went backwards: > delta=-70033718 delta_cpu=66347002 shadow=299 > 3571302800 off=838831281 processed=2994480167600 cpu_processed=2994343786880 > Jan 19 00:11:09 server kernel: 0: 2994480167600 > Jan 19 00:11:09 server kernel: 1: 2994343786880 > > This happens also if I switch manually with > cpufreq-set -f 2.60GHz of cpufrequtils. It seems to happen most reliably when there's a large jump in frequency (2.6 GHz to 800 MHz or vice versa) but I've seen it happen for smaller switches. Usually there's 1 large backward movement, and then 2-4 smaller ones. It doesn't always happen, especially if there are multiple shifts in a short period (ie, constant changes on the ondemand governor) and it seems to happen more consistently when increasing frequency. > Are you sure the systems aren't overheating and performing emergency > T-state thermal throttling? Yes. The same machine that instantly has time going backwards after a pstate change can stay at that pstate for hours without any time issues, whether its a low pstate or a high pstate. -Mark Langsdorf Operating System Research Center AMD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |