[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100419180032.15586a90@infradead.org>
Date: Mon, 19 Apr 2010 18:00:32 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Salman Qazi <sqazi@...gle.com>, mingo@...e.hu,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
svaidy@...ux.vnet.ibm.com, linux-pm@...ts.linux-foundation.org,
csadler@...gle.com, ranjitm@...gle.com, kenchen@...gle.com,
dawnchen@...gle.com
Subject: Re: [PATCH 0/3] [idled]: Idle Cycle Injector for power capping
On Mon, 19 Apr 2010 21:01:41 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> Right, so the IBM folks who were looking at power aware scheduling
> were working on an interface to quantify the amount of power to save.
>
> But their approach, was an extension of the regular power aware
> load-balancer, which basically groups tasks onto sockets so that whole
> sockets can go idle.
>
> However Arjan explained to me that your approach, which idles the
> whole machine, has the advantage that also memory banks can go into
> idle mode and save power.
>
> Still in the interest to cut back on power-saving interfaces it would
> be nice to see if there is anything we can do to merge these things,
> but I really haven't thought much about that yet.
one correction, this is not about power *saving*, it is about power
*capping*. Power capping is pretty much energy inefficient by
definition (and surely in practice), but it's about dealing with
reality about underdimensioned airconditioning or voltage rails....
Due to the reality that socket offlining isn't as good as idle
insertion.. I rather focus on the later...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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