Date: Wed, 23 Jan 2013 16:58:19 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org, Ian Lepore <ian@FreeBSD.org> Subject: Re: time issues and ZFS Message-ID: <50FFFA8B.4040008@FreeBSD.org> In-Reply-To: <CAJ-VmokQbZFGmmy=KkEmP%2B7a6DQRGhdgupqF4sNCGJYxvA-B0g@mail.gmail.com> References: <E1TxFcr-0006dx-MX@kabab.cs.huji.ac.il> <1358780588.32417.414.camel@revolution.hippie.lan> <E1TxJP2-000DS8-DJ@kabab.cs.huji.ac.il> <1358783667.32417.434.camel@revolution.hippie.lan> <CAJ-Vmo=2Dmf4Lb-uoUQDrybyRSS=_bnV5KcNYGg5MnMxfhhu7w@mail.gmail.com> <E1TxYHa-0002yo-4Y@kabab.cs.huji.ac.il> <CAJ-VmomdQORjs55ooW55Rgg0i1M13PPtnmCPRrp__btEWQz=4g@mail.gmail.com> <E1TxaZv-0005fj-5m@kabab.cs.huji.ac.il> <CAJ-VmokQbZFGmmy=KkEmP%2B7a6DQRGhdgupqF4sNCGJYxvA-B0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 22/01/2013 20:42 Adrian Chadd said the following: > Hi! > > As I said before, the problem with non-HLT loops with event-timer in > -9 and -head is that it calls the idle function inside a critical > section (critical_enter and critical_exit) which blocks interrupts > from occuring. > > The EI;HLT instruction pair on i386/amd64 atomically and correctly > handles things from what I've been told. > > However, there's no atomic way to do this using ACPI sleeping, so > there's a small window where an interrupt may come in but it isn't > handled; waiting for the next interrupt to occur before it'll wake up > and respond to that interrupt. I don't think that this is true of x86 hardware in general. You might have hit some limitation or a quirk or a bug or an erratum for some particular hardware. E.g. a chipset on this machine has a bit described as such: "Set to 1 to skip the C state transition if there is break event when entering C state." The bit is set indeed and as far as I can tell the behavior matches the description. Most modern (non-embedded) machines seem to behave this way. Attempt to enter a deeper C state while a break event is pending still incurs some overhead, but it's not as bad as waiting for the next break event. > I kept hitting my head against this when doing network testing. :( > > Now - specifically for timekeeping it shouldn't matter; that's to do > with whether the counters are reliable or not (and heck, are even in > lock-step on CPUs.) But extra latency could show up weirdly, hence why > I was asking for you to try different timer configurations and idle > loops. -- Andriy Gapon -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50FFFA8B.4040008>