Messages in this thread | | | Date | Fri, 11 Nov 2005 08:38:41 +0100 | From | Ingo Molnar <> | Subject | Re: IO-APIC problem with 2.6.14-rt9 |
| |
* john stultz <johnstul@us.ibm.com> wrote:
> > yes. traces show that the new calibration code results in a bogomips > > value on Athlon64 CPUs that halve the timeout. I.e. udelay(100) now > > takes 50 usecs (!). The calibration code seems to assume the number of > > cycles == number of loops in __delay() - that is not valid. > > Yea, that makes sense, because the READ_CURRENT_TIMER calibration is > all TSC based and with my code we use the loop based delay (since the > TSC based one can have a number of problems). So that doesn't mesh > well when the loop/cycle values are not equivalent. > > That still leaves open the question why Dinakar is seeing issues w/ > the loop based calibration, but I've got some similar hardware in my > lab, so I can probably work that out. > > I'll see if I can't avoid touching the delay code. Its such a sketchy > calibration sensitive code path that I'd really like to see it killed, > but maybe there's something simple that can be done. > > Grumble. :( I was hoping to submit my tod code to Andrew tomorrow, but > this might block that.
hm, ARCH_HAS_READ_CURRENT_TIMER is upstream already. I have not measured the udelay thing upstream, but i thought it would have the same issue. Does the GTOD code impact this code?
Ingo - 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/
| |