[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1395102010.2474.21.camel@buesod1.americas.hpqcorp.net>
Date: Mon, 17 Mar 2014 17:20:10 -0700
From: Davidlohr Bueso <davidlohr@...com>
To: mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, hpa@...ux.intel.com, len.brown@...el.com,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86 idle: Repair large-server 50-watt
idle-power regression
On Thu, 2013-12-19 at 11:51 -0800, tip-bot for Len Brown wrote:
> Commit-ID: 40e2d7f9b5dae048789c64672bf3027fbb663ffa
> Gitweb: http://git.kernel.org/tip/40e2d7f9b5dae048789c64672bf3027fbb663ffa
> Author: Len Brown <len.brown@...el.com>
> AuthorDate: Wed, 18 Dec 2013 16:44:57 -0500
> Committer: H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Thu, 19 Dec 2013 11:47:39 -0800
>
> x86 idle: Repair large-server 50-watt idle-power regression
FYI this commit can cause some non trivial performance regressions for
larger core count systems. While not surprising because of the nature of
the change, having intel_idle do more cacheline invalidations, I still
wanted to let you guys know. For instance, on a 160 core Westmere
system, aim7 throughput can go down in a number of tests, anywhere from
-10% to -25%.
I guess it comes down to one of those performance vs energy things. And
sure, max_cstate can be set to overcome this, but it's still something
that was previously taken for granted.
Thanks,
Davidlohr
--
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/
Powered by blists - more mailing lists