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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"