| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
As suggested by Ingo, remove all references to tsc from init/calibrate.c
TSC is x86 specific, and using tsc in variable names in a generic file should
be avoided. lpj_tsc is now called lpj_fine, since it is related to fine tuning
of lpj value. Also tsc_rate_* is called timer_rate_*
Signed-off-by: Alok N Kataria <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Daniel Hecht <[email protected]>
Cc: Tim Mann <[email protected]>
Cc: Zach Amsden <[email protected]>
Cc: Sahil Rihan <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
On the x86 platform we can use the value of tsc_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.
Does some formating changes to lpj_setup code to now have a single
printk to print the bogomips value.
We do this only for the boot processor because the AP's can have
different base frequencies or the BIOS might boot a AP at a different
frequency.
Signed-off-by: Alok N Kataria <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Daniel Hecht <[email protected]>
Cc: Tim Mann <[email protected]>
Cc: Zach Amsden <[email protected]>
Cc: Sahil Rihan <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
We should be able to do ndelay(some_u64), but that can cause a call to
__divdi3() to be emitted because the ndelay() macros does a divide.
Fix it by switching to static inline which will force the u64 arg to be
treated as an unsigned long. udelay() takes an unsigned long arg.
[[email protected]: reported m68k build breakage]
Cc: Adrian Bunk <[email protected]>
Cc: Evgeniy Polyakov <[email protected]>
Cc: Martin Michlmayr <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Adrian Bunk <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
On partitioned PPC64 systems where a partition is given 1/10 of a
processor, we have seen mdelay() delaying for 10 times longer than it
should. The reason is that the generic mdelay(n) does n delays of 1
millisecond each. However, with 1/10 of a processor, we only get a
one-millisecond timeslice every 10ms. Thus each 1 millisecond delay
loop ends up taking 10ms elapsed time.
The solution is just to use the PPC64 udelay function, which uses the
timebase to ensure that the delay is based on elapsed time rather than
how much processing time the partition has been given. (Yes, the
generic mdelay uses the PPC64 udelay, but the problem is that the
start time gets reset every millisecond, and each time it gets reset
we lose another 9ms.)
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Acked-by: Andrew Morton <[email protected]>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|