Date: Sun, 13 Jan 2013 16:10:01 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Alexander Motin <mav@freebsd.org> Cc: Davide Italiano <davide@freebsd.org>, freebsd-arch@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, Marius Strobl <marius@alchemy.franken.de> Subject: Re: [RFC/RFT] calloutng Message-ID: <1358118601.32417.41.camel@revolution.hippie.lan> In-Reply-To: <50F30CAB.3000001@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: [...] > > > > Uhm, there are no NMIs on sparc64. Does it make sense to bypass this > > adjustment on sparc64? > > If it is not possible or not good to to stop timer during programming, > there will always be some race window between code execution and timer > ticking. So some minimal safety range should be reserved. Though it > probably can be significantly reduced. In case of x86/HPET there is > additional factor of NMI, that extends race to unpredictable level and > so makes additional post-read almost mandatory. > > >> May be with rereading counter > >> after programming comparator (same as done for HPET, reading which is > >> probably much more expensive) this value could be reduced. > > > > I see. There are some bigger fish to fry at the moment though :) > Speaking of the HPET code, it seems to me that its restart logic can fire the same event twice. Is that harmless? -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358118601.32417.41.camel>