From: EXT Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] Sent: Tuesday, October 27, 2015 7:23 PM To: Peter Maydell <peter.mayd...@linaro.org> Cc: Dmitry Osipenko <dig...@gmail.com>; Krzeminski, Marcin (Nokia - PL/Wroclaw) <marcin.krzemin...@nokia.com>; qemu-devel@nongnu.org Subject: Re: arm mptimer implementation - why prescaler is multiply by 10?
On Tue, Oct 27, 2015 at 11:19 AM, Peter Maydell <peter.mayd...@linaro.org<mailto:peter.mayd...@linaro.org>> wrote: On 27 October 2015 at 18:01, Peter Crosthwaite <crosthwaitepe...@gmail.com<mailto:crosthwaitepe...@gmail.com>> wrote: > On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko > <dig...@gmail.com<mailto:dig...@gmail.com>> 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.
