Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751614AbbKET23 (ORCPT ); Thu, 5 Nov 2015 14:28:29 -0500 Received: from mga11.intel.com ([192.55.52.93]:17799 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806AbbKET22 (ORCPT ); Thu, 5 Nov 2015 14:28:28 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,248,1444719600"; d="scan'208";a="843517787" Date: Thu, 5 Nov 2015 11:27:32 -0800 From: Jacob Pan To: Peter Zijlstra Cc: Thomas Gleixner , LKML , Arjan van de Ven , Paul Turner , Len Brown , Srinivas Pandruvada , Tim Chen , Andi Kleen , Rafael Wysocki , jacob.jun.pan@linux.intel.com Subject: Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection Message-ID: <20151105112732.7f600ba8@icelake> In-Reply-To: <20151105100922.GA3604@twins.programming.kicks-ass.net> References: <1446509428-5616-1-git-send-email-jacob.jun.pan@linux.intel.com> <1446509428-5616-4-git-send-email-jacob.jun.pan@linux.intel.com> <20151103133120.GD17308@twins.programming.kicks-ass.net> <20151103084501.289ec5d1@yairi> <20151105100922.GA3604@twins.programming.kicks-ass.net> Organization: OTC X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1155 Lines: 29 On Thu, 5 Nov 2015 11:09:22 +0100 Peter Zijlstra wrote: > > Before: > > CPU0 ______||| || |___________| || || |_____ > > CPU1 _________||| || |_______| || |_______ > > > > After: > > > > CPU0 ______||| || |___________| || || |_____ > > CPU1 ______||| || |___________| || |_______ > > > > The goal is to have overlapping idle time if the load is already > > balanced. The energy saving can be significant. > > I can see such a scheme having a fairly big impact on latency, esp. > with forced idleness such as this. That's not going to be popular for > many workloads. agreed, it would be for limited workload. the key is to identify such workloads at runtime. I am thinking to use the load average of the busiest CPU as reference for consolidation, will not go beyond that. For the patch I have today and if you play a game like this one http://www.agame.com/game/cut-the-rope -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/