Erroneous package power limit notification since kernel 2.6.39

Jesse Barnes jbarnes at virtuousgeek.org
Fri Jul 22 09:10:37 PDT 2011


On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer <aaron667 at gmx.net> wrote:

> Am 29.06.2011 00:06, schrieb Jesse Barnes:
> > On Wed, 29 Jun 2011 00:01:58 +0200
> > Olaf Freyer <aaron667 at gmx.net> wrote:
> >
> >> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> >>> Ok interesting, didn't realize X startup was so GPU intensive. :)
> >>>
> >>> The patch you reverted will definitely cause the GPU to ramp up its
> >>> frequency much faster than before, but it sounds like on your system
> >>> you might also see it with the revert if you run something GPU
> >>> intensive like nexuiz.
> >>>
> >>> The CPU (and by extension the GPU) will take care of itself though; if
> >>> things get too hot or over power, it will clock throttle to keep itself
> >>> in a safe range.
> >> I also see the message alot during my daily average usage of my computer
> >> (just using Firefox, Thunderbird and IntelliJ) - seeing things like
> >> CPU3: Package power limit notification (total events = 90809)
> >> after a normal day in the office became normal since 2.6.39.
> >>
> >> I just gave nexuiz a try for about 30 minutes with the reversal patch
> >> applied -
> >> and not a single message appeared in my logs.
> > Sounds like with the patch reverted we can't drive your GPU and CPU
> > hard enough to generate the messages.  Not sure if that's a good thing
> > or a bad thing though...
> >
> I'm not sure either. I saw a single notification event yesterday while
> in office -
> previously I would have recieved 70000-90000 during that timeframe.
> I consider the pure amount of notifications unsettling - and in case of
> some
> "real" issue it might even get lost inbetween those notifications.
> 
> Maybe there is a possible compromise between the situation before and
> after the patch? I'm willing to lose a few percent of GPU performance just
> for the sake of getting lost of those notification events...

Yeah we can probably tune these values a bit better...  I'll see about
doing that.  We want to maximize performance across a variety of
workloads, but not hit the power limit so hard even for basic stuff...

-- 
Jesse Barnes, Intel Open Source Technology Center


More information about the dri-devel mailing list