Hey guys, I tested this issue fairly thoroughly. My conclusion is that the 'clocksource=jiffies' kernel param fixes the clock instability issue, while other suggested solutions don't. It might be a good idea to shift over to clocksource= being the default param in FSConfig.py if people feel checkpoint+restore with CPU frequency changes is a common occurrence. More details below my signature.
Anyone have further input? Thanks, Joel Details for future reference for anyone that runs into this: I was experiencing this clocksource unstable issue in x86 FS mode using the Ruby memory hierarchy, gem5 revision 9882:372d3611c693. I collected checkpoints after booting Linux using 2GHz CPU cores, and I was restoring from those checkpoints into 4GHz cores, which were causing the kernel clock to be incorrect and triggering this message. It was also causing the terminal output to stop printing (hang), so I wasn't able to check the benchmark results. Andreas' suggestion of replacing 'lpj=xxx' with 'clocksource=jiffies' for the kernel parameters (boot_osflags in FSConfig.py) works to side-step the issue. Specifically, I recollected checkpoints with the clocksource kernel param, and am now able to restore into sims with CPUs of any frequency, because the kernel clock is based on the count of timer interrupts rather than CPU cycles. Note that this side-steps the issue in that it uses the count of timer interrupts to count jiffies as the time quanta rather than basing the clock on values read from the tsc register. For gem5, this may be an alright solution given that we have complete control over the interrupts timer device, and simulation times are generally not very long. I also tested Andreas' other suggestions, but none of those fixed this issue. Using the tsc=reliable option, the kernel still does the stability check. The 'notsc' option also failed, but in my testing, it was because the kernel needs to be configured+compiled to allow this flag to be passed. I did not test reconfiguring+recompiling the kernel. On Mon, Jul 22, 2013 at 5:12 PM, Mahshid Sedghi <mahshid.sed...@gmail.com>wrote: > Thanks a lot Andreas for the detailed explanation. I will try your > proposed solutions. > > Mahshid > > > On Fri, Jul 19, 2013 at 4:37 AM, Andreas Sandberg > <andr...@sandberg.pp.se>wrote: > >> On 07/18/2013 06:06 PM, Mahshid Sedghi wrote: >> >>> I was wondering if anybody has experienced this prompt when running in >>> x86 FS mode: >>> >>> Clocksource tsc unstable (delta = <some big number> ns) >>> >>> Apparently this message is shown when the system has multiple available >>> clock sources. When running gem5 in the mentioned mode, this message is >>> occasionally shown and usually stops the execution from proceeding. Is >>> there a solution to fix the problem? >>> >> >> I haven't seen it in any of the normal CPU models, but I have similar >> issues when using KVM (hardware virtualization) in gem5. Depending on what >> causes this problem and your kernel version you could try one of the >> following: >> >> * Switch to a different clocksource. For example, append >> "clocksource=jiffies" to the kernel command line (see boot_osflags in >> FSConfig.py if you are using the example scripts). >> * Force the kernel to treat the TSC as reliable (append "tsc=reliable") >> * Disable the TSC (append "notsc"). The kernel should automatically >> choose a different clocksource if you append this option. >> >> Also, your kernel might be slightly confused if you have changed the >> clock frequency of your CPU without removing/updating the "lpj=x" option as >> this forces the kernel to use a timing calibrated for a different CPU. >> >> Yet another possibility is that you have an old version of gem5 that has >> a bug that causes the TSC to jump (sometimes backwards) when switching >> CPUs. That was fixed by HG changeset e039a48eeb99 (git: 0b4a8b4086). >> >> //Andreas >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
