Date: Tue, 24 Aug 2010 15:34:09 -0700 From: "Kevin Oberman" <oberman@es.net> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-current@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related Message-ID: <20100824223409.7E0941CC3A@ptavv.es.net> In-Reply-To: Your message of "Mon, 23 Aug 2010 11:56:17 PDT." <4C72C451.4070407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Mon, 23 Aug 2010 11:56:17 -0700 > From: Doug Barton <dougb@FreeBSD.org> > Sender: owner-freebsd-current@freebsd.org > > On 08/23/2010 05:39, John Baldwin wrote: > > On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote: > >> Thanks to help from Andriy I've been working on narrowing down the cause > >> of my "runaway intr" problems and we've found some interesting things. > >> First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than > >> C1 things seem to work fine. Using one or the other sort of works, but > >> between the 2 powerd seems to cause the most problems. > > > > I think this just means that when C3 is enabled the system is getting skewed > > results in cp_time[] and so the stats are off. The system isn't actually > > stuck in an interrupt storm of sorts, the numbers reported to top are just > > wrong so it looks like it is. > > That may be true, however what's happening at that time is that the > video and audio both become choppy (as in, painfully so) and every other > thing that's running, whether it's desktop clients like thunderbird or > something being compiled, also moves very very slow, as if it's > resource-starved. So while I'm perfectly ready to admit that the top > output may be just a symptom instead of the real problem, something > fundamentally bad IS happening under the hood. This sounds wrong. C3 should only be entered when a CPU is halted for an extended time. When I am plying a movie, I never see C3, but I am using an old uniprocessor on my T43. I would believe that dropping to C3 could be detrimental to playing video as it takes quite a few clock cycles for the system to climb out of C3 and start doing real work again. Things that come to mind...does the player move between CPUs while this is going on? Does ULE take processor ACPI state into account when scheduling? Can you try locking the player to a single CPU with cpuset(1) so it does not move around? Try different CPUs. Some are more equal than others, at least in my network performance testing using FreeBSD and I have been unable to figure out, other than empirically, which ons(s) work best. just some random thoughts from an un-air conditioned office on a very hot afternoon in Berzerkley. I may simply be delirious. :-) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100824223409.7E0941CC3A>