From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcqLR-0002Vv-3h for qemu-devel@nongnu.org; Tue, 02 Oct 2007 18:36:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcqLP-0002Sm-Od for qemu-devel@nongnu.org; Tue, 02 Oct 2007 18:36:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcqLP-0002Rt-Fe for qemu-devel@nongnu.org; Tue, 02 Oct 2007 18:35:59 -0400 Received: from ftp.linux-mips.org ([194.74.144.162]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IcqLP-0008Ti-4x for qemu-devel@nongnu.org; Tue, 02 Oct 2007 18:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1]:19099 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023665AbXJBWfu convert rfc822-to-quoted-printable (ORCPT ); Tue, 2 Oct 2007 23:35:50 +0100 Date: Tue, 2 Oct 2007 23:35:47 +0100 From: Ralf Baechle Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel Message-ID: <20071002223547.GA21687@linux-mips.org> References: <20071002200644.GA19140@hall.aurel32.net> <4702A99B.7020008@qumranet.com> <4702AC0F.1000906@aurel32.net> <20071002214826.7ee2fae8@the-village.bc.nu> <4702B0B4.6080909@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: QUOTED-PRINTABLE In-Reply-To: <4702B0B4.6080909@aurel32.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: linux-mips@linux-mips.org, qemu-devel@nongnu.org, Alan Cox On Tue, Oct 02, 2007 at 10:57:24PM +0200, Aurelien Jarno wrote: > From: Aurelien Jarno > Date: Tue, 02 Oct 2007 22:57:24 +0200 > To: Alan Cox > CC: qemu-devel@nongnu.org, linux-mips@linux-mips.org > Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel > Content-Type: text/plain; charset=3DISO-8859-1 >=20 > Alan Cox a =E9crit : > >> Well on real hardware, the instruction rate and the timer are link= ed: > >> the timer run at half the speed of the CPU. As the corresponding > >> assembly code is very small, only uses registers and is run in ker= nel > >> mode, you know for sure that 48 cycles is more than enough. > >=20 > > What happens on NMI or if you take an ECC exception and scrubbing s= tall > > off the memory controller while loading part of that cache line of = code > > into memory ? > >=20 >=20 > The code returns -ETIME, and the function is run again with the minim= um > delay. >=20 > So as long as you don't have an exception every time, the code works. The current setting should be safe on real hardware - but a value of just 48 cycles for max_delta_ns is probably lower than the lowest useful value, so I don't mind raising it. This number really is a tunable. Ralf