Blue Swirl wrote: > 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()?
I would suggest that you implement your ideas now. Please keep us informed about the progress as this series (and more) depends on a decision. Jan
signature.asc
Description: OpenPGP digital signature
