[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1521635467.6308.13.camel@surriel.com>
Date: Wed, 21 Mar 2018 08:31:07 -0400
From: Rik van Riel <riel@...riel.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Peter Zijlstra <peterz@...radead.org>,
Linux PM <linux-pm@...r.kernel.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Thomas Ilsche <thomas.ilsche@...dresden.de>,
Doug Smythies <dsmythies@...us.net>,
Aubrey Li <aubrey.li@...ux.intel.com>,
Mike Galbraith <mgalbraith@...e.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFT][PATCH v7 0/8] sched/cpuidle: Idle loop rework
On Tue, 2018-03-20 at 16:12 +0100, Rafael J. Wysocki wrote:
> Hi All,
>
> Thanks a lot for the feedback so far!
>
> Respin after recent comments from Peter.
>
> Patches [1-3] unmodified since v5, patch 4 is new and the other ones
> have been updated to address feedback.
>
> The previous summary that still applies:
For some reason I see increased CPU utilization
with this patch series (75% -> 85%) with the same
rate of requests being handled by the vanilla
kernel and a kernel with these patches applied.
I am running a bisect in the series to see what
change could possibly cause that, and also digging
through system statistics to see whether it might
be something as perverse as not mistakenly choosing
deeper C-states on one core causing other cores to
miss out on turbo mode...
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists