On Sat, May 29, 2010 at 10:16 AM, Jan Kiszka <jan.kis...@web.de> wrote: > Blue Swirl wrote: >>>>> This is - according to my current understanding - the proposed >>>>> alternative architecture: >>>>> >>>>> .---------------. >>>>> | de-coalescing | >>>>> | logic | >>>>> '---------------' >>>>> ^ | >>>>> period,| |IRQ >>>>> coalesced| |(or tuned VM clock) >>>>> (yes/no)| v >>>>> .-------. .--------. .-------. >>>>> | RTC |-----IRQ----->| router |-----IRQ---->| APIC | >>>>> '-------' '--------' '-------' >>>>> | ^ | ^ >>>>> | | | | >>>>> '-------period-------' '------period-------' >>>> The period information is already known by the higher level clock >>>> management, >>> The timer device models program the next event of some qemu-timer. There >>> is no tag attached explaining the timer subsystem or anyone else the >>> reason behind this programming. >> >> Yes, but why would we care? All timers in the system besides RTC >> should be affected likewise, this would in fact be the benefit from >> handling the problem at higher level. > > And how does your equation for calculating the clock slow-down look like?
How about icount_adjust()?
