In some workloads, for example web servers talking to database servers,
a task on one CPU will wake up a task on another CPU, wait for that
other CPU to handle the job, and get the result back. Each of those
wakeups is likely to incur the c-state exit latency.
By only counting the exit latency once, even though the round trip
involves two c-state exits, we can end up going into too deep a
c-state for the workload.
Signed-off-by: Rik van Riel <r...@redhat.com>
---
drivers/cpuidle/governors/menu.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 47b1150..ccdb348 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -378,10 +378,13 @@ static void menu_update(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
/*
* We correct for the exit latency; we are assuming here that the
* exit latency happens after the event that we're interested in.
+ * Pessimistically assume that we got woken up by another CPU,
+ * so we count its exit latency, too.
*/
- if (measured_us > data->exit_us)
- measured_us -= data->exit_us;
-
+ if (measured_us > 2 * data->exit_us)
+ measured_us -= 2 * data->exit_us;
+ else
+ measured_us = 0;
/* update our correction ratio */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
