From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zroyt-0003Uk-Tz for qemu-devel@nongnu.org; Thu, 29 Oct 2015 11:19:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zroyp-0005ee-8o for qemu-devel@nongnu.org; Thu, 29 Oct 2015 11:19:11 -0400 Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:35511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zroyp-0005eK-1N for qemu-devel@nongnu.org; Thu, 29 Oct 2015 11:19:07 -0400 Received: by lbbes7 with SMTP id es7so30925907lbb.2 for ; Thu, 29 Oct 2015 08:19:06 -0700 (PDT) References: <562F8807.2090107@gmail.com> From: Dmitry Osipenko Message-ID: <563238AD.1090608@gmail.com> Date: Thu, 29 Oct 2015 18:18:05 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Krzeminski, Marcin (Nokia - PL/Wroclaw)" , EXT Peter Crosthwaite , Peter Maydell Cc: "qemu-devel@nongnu.org" 29.10.2015 10:00, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет: > *From:*EXT Peter Crosthwaite [mailto:crosthwaitepeter@gmail.com] > *Sent:* Tuesday, October 27, 2015 7:23 PM > *To:* Peter Maydell > *Cc:* Dmitry Osipenko ; Krzeminski, Marcin (Nokia - > PL/Wroclaw) ; 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 > wrote: > > On 27 October 2015 at 18:01, Peter Crosthwaite > > wrote: > > On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko > 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? > Both, but it depends on your application and if there is no proper RTC onboard. > > > 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. > Exactly. Once kernel reaches NFS mount here, it starts to suffer. -- Dmitry