linux-kernel - Re: Performance/resume issues on Toshiba NB305

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: <alpine.LFD.2.00.1102252330290.2701@localhost6.localdomain6>
Date:	Fri, 25 Feb 2011 23:40:34 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Seth Forshee <seth.forshee@...onical.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Len Brown <lenb@...nel.org>,
	Burt Triplett <burt@...triplett.org>
Subject: Re: Performance/resume issues on Toshiba NB305

On Fri, 25 Feb 2011, Seth Forshee wrote:

> On Fri, Feb 25, 2011 at 10:47:16PM +0100, Thomas Gleixner wrote:
> > Let's wait for the intel and acpi folks. It would be interesting what
> > the new intel toy says to your BIOS.
> > 
> >     http://biosbits.org/
> 
> Not much because it doesn't know about my processor. About all I could
> get out of it is that my MSRs are inconsistent, SMI latency is bad, and
> the round-trip latency via MWAIT test gives elapsed time = 285ms with
> 229 iterations/ms.

Ouch.
 
> > > Then there must be a bug. When I cleared CLOCK_EVT_FEAT_ONESHOT for the
> > > HPET without this change the HPET got put into oneshot mode. The local
> > > tick device is checked before switching to nohz, but not the broadcast
> > > device. This change was just a quick hack to get around that and test my
> > > theory.
> > 
> > Indeed. The patch below should cure that.
> 
> It works. I was wondering whether or not I should put the broadcast
> device in periodic mode with the local ones in nohz; I guess your patch
> answers my question.

Well, there is no point having the local ones in nohz mode when
broadcast one does not support it. You only get power saving when your
box stays in deep power modes for a long time. So with the BC periodic
it will try to go into deep power states (not knowing about the
periodic BC issue) and pop out of it in the same way as you do with
nohz disabled. So the power saving effect is approx. zero.

Thanks,

	tglx
--
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/