Messages in this thread | | | Date | Tue, 3 Jun 2008 21:01:54 -0700 | From | "Alok kataria" <> | Subject | Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation |
| |
On Tue, Jun 3, 2008 at 6:20 PM, Arjan van de Ven <arjan@infradead.org> wrote: > On Tue, 03 Jun 2008 17:41:09 -0700 > Alok Kataria <akataria@vmware.com> wrote: > >> On X86 platform we can use the value of cpu_khz computed during tsc >> calibration to calculate the loops_per_jiffy value. Its very >> important to keep the error in lpj values to minimum as any error in >> that may result in kernel panic in check_timer. >> In virtualization environment on a highly overloaded host, the guest >> delay calibration may sometimes result in errors beyond the ~50% that >> timer_irq_works can handle, resulting in the guest panicking. > \ > > can you guarantee that the rate tsc ticks at is the same as the current > CPU frequency? Answer: You can't.... >
I think at the boot time atleast we can assume that, no ? If you are referring to the cpu frequency changing at run time (aka dynamic frequency scaling), in that case the time_cpufreq_notifier should take care of updating the loops_per_jiffy value for that corresponding cpu.
> sadly we do need to calibrate this... > > In addition, clearly you can have different cpus in a system run at a > different rate (both in terms of cpu_khz and, independently, in terms > of tsc rate) >
Again yes at run time frequency's may change but they shouldn't at boottime. AFAIK, i don't think there are X86 MP systems with asymmetric cpus i.e. systems with different base frequencies. If thats not true then there sure is a problem.
Thanks, Alok
> > -- > If you want to reach me at my work email, use arjan@linux.intel.com > For development, discussion and tips for power savings, > visit http://www.lesswatts.org > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
| |