From: EXT Peter Crosthwaite [mailto:[email protected]] Sent: Tuesday, October 27, 2015 7:23 PM To: Peter Maydell <[email protected]> Cc: Dmitry Osipenko <[email protected]>; Krzeminski, Marcin (Nokia - PL/Wroclaw) <[email protected]>; [email protected] Subject: Re: arm mptimer implementation - why prescaler is multiply by 10?
On Tue, Oct 27, 2015 at 11:19 AM, Peter Maydell <[email protected]<mailto:[email protected]>> wrote: On 27 October 2015 at 18:01, Peter Crosthwaite <[email protected]<mailto:[email protected]>> wrote: > On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko > <[email protected]<mailto:[email protected]>> wrote: >> From my observation, Linux kernel is booting noticeably faster in the >> emulated guest and host machine CPU usage is lower if we "artificially" >> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that >> trick shouldn't affect guest behavior. Do you mean qemu or real hw? > So I do wonder whether with your ptimer conversion this will be obsoleted, > as the rate limiter there may do the work for us. We still need to pick a nominal PERIPHCLK somehow, and that's still a pretty arbitrary choice I think (and it doesn't depend on the CPU speed itself: PERIPHCLK's period can be any multiple of the main CPU CLK (minimum 2)). Yep. But is it nice to know if we can move towards board level configuration of this without the rate-limiting problem. Rather than a 10x rate limiter it should be a QOM property for PERIPHCLK frequency. Regards, Peter thanks -- PMM I made some tests by changing implementation to work with PERIPHCLK=600MHz, and in fact overhead was to high to work comfortably with linux guest, but the key problem was networking.
