linux-kernel - Re: acpi_idle: Very idle Core i7 machine never enters C3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100205160900.GA2736@jgarrett.org>
Date:	Fri, 5 Feb 2010 10:09:00 -0600
From:	Jeff Garrett <jeff@...rrett.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, Len Brown <lenb@...nel.org>,
	linux-acpi@...r.kernel.org
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, Jan 26, 2010 at 10:45:20PM +0100, Andi Kleen wrote:
> jeff@...rrett.org (Jeff Garrett) writes:
> 
> > Hi,
> >
> > I was trying to chase down a theory that my desktop machine (a core i7)
> > is running warm (the fan sounds like it's at full speed all the time,
> > and I think it's not always acted this way -- hence the theory).
> >
> > powertop is never showing it spending any time in C3...
> >
> > I compiled a kernel without USB/sound/radeon, and ran without X.  I was
> > able to get the wakeups/sec down below 20, but no time is spent in C3.
> 
> [...]
> > This may be a complete red herring, but I added some printk logic to
> > acpi_idle_bm_check(), and it is getting called often, but bm_status is
> > always 1.  [I infer from this that the idle logic is trying to go into
> > C3, but this check is stopping it...  Unless I misread something.]
> 
> Normally a Core i7 (or any modern Intel systems) should not use
> bm_check at all. That's only for older systems that didn't support
> MWAIT with c-state hint, but relied on the old port based interface. 

bm_check = 1, bm_control = 0

I don't know what any of this means.  :)

I tried changing processor_idle.c.  It reads (for C3):
1106                         state->enter = pr->flags.bm_check ?
1107                                         acpi_idle_enter_bm :
1108                                         acpi_idle_enter_simple;

So it always calls acpi_idle_enter_bm in my case.  I tried modifying it
to call acpi_idle_enter_simple for entering C3 instead.  When I did
this, it did make it into C3 according to powertop, but the wakeups per
second grew by at least 10x.  I couldn't get that below ~400-800/s, and
the residency in C3 was limited to about ~50%, as reported by powertop.

> So something is already confused there.

Might just be me.  :)

> I think it should still work though.
> Of course if you really have a lot of bus mastering in the background
> then yes there will be no C3.
> 
> -Andi

I have no idea what counts as bus mastering (is it just DMA transfers to
PCI devices?)...  But with a fairly idle system, with things like USB
configured out, what could be doing it if it exists?  Would there be
some nice function I could instrument with a few printk's to, to see?  I
compiled with PCI_DEBUG=y, and "bus master" doesn't show up in the
dmesg.

-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/