Hi Thomas, thank you very much for the reply. > Please do _NOT_ top post. Please reply inline and in context. Sorry for that... > > The issue is here, that the interrupt routine of the kernel > > takes too long here. > > It would be fine to have the timer interrupt called more > > often and to process with each call only a subset of the > > jobs to be done... > > This would reduce the time the CPU the user mode > > is interrupted by the timer routine. > > Err, by splitting the work you introduce even more overhead. That's > the wrong approach. The first question is which timers are running on > that CPU as you have isolated it. You are right. The total overhead is of course larger. However, the overhead that could appear within a single of our 40us loops would be smaller. It is fine for me to have a 5us add on with each loop. But it is not allowed to have a 15us add on with every 1000th loop... > > In theory it's possible to remove the timer interrupt from such an > isolated core completely, but there needs to be some work done vs. the > scheduler, accounting, RCU etc. There are people looking into this, > but we have no patches yet. I have checked the LAPIC addresses via the MSRs. All LAPIC addresses for all CPU cores are the same. I assume they share the very same configuration, thus a minimum step would be to make a copy of this configuration data and to let CPU core 3 point to this copy. This would allow to disable the timer. > > What kind of application is that ? Data acquistion or closed loop > processsing ? I am running a close loop application. Thank you very much. Regards Mathias -- Mathias Koehrer mathias_koehrer@xxxxxxxx Tolle Dekolletés oder scharfe Tatoos? Vote jetzt ... oder mach selbst mit und zeige Deine Schokoladenseite bei Topp oder Hopp von Arcor: http://www.arcor.de/rd/footer.toh -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
