From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 14:58:22 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D115747; Wed, 23 Jan 2013 14:58:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 80D1E8AD; Wed, 23 Jan 2013 14:58:21 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA11268; Wed, 23 Jan 2013 16:58:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50FFFA8B.4040008@FreeBSD.org> Date: Wed, 23 Jan 2013 16:58:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: time issues and ZFS References: <1358780588.32417.414.camel@revolution.hippie.lan> <1358783667.32417.434.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 14:58:22 -0000 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