public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: arun@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org, ego@in.ibm.com,
	tglx@linutronix.de, mingo@elte.hu, a.p.zijlstra@chello.nl,
	andi@firstfloor.org, venkatesh.pallipadi@intel.com,
	vatsa@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/1]: timers: Timer Migration
Date: Tue, 16 Sep 2008 06:53:45 -0700	[thread overview]
Message-ID: <20080916065345.76d052e1@infradead.org> (raw)
In-Reply-To: <20080916091219.GA1068@linux.vnet.ibm.com>

On Tue, 16 Sep 2008 14:42:31 +0530
Arun R Bharadwaj <arun@linux.vnet.ibm.com> wrote:

> Hi,
> 
> An idle cpu on which device drivers have initialized timers, has to
> be frequently woken up to service the timers. So, consolidation of
> timers onto a fewer number of cpus is important. Migration of timers
> from idle cpus onto lesser idle cpus is necessary. Currently, timers
> are migrated during the cpu offline operation. However cpu-hotplug
> for the sake of idle system power management is too heavy. So, this
> patch implements a lightweight timer migration framework.

while I absolutely like reducing power consumption... I'm not sure this
helps or is the right approach.

First of all, it's of course absolutely better to fix timers and apps
that cause them (and with PowerTOP we fixed basically all the bad
stuff).

Second, in terms of power; a wake up is a wake up, it doesn't really
matter where it happens. 

Now we could do some consolidation (which realistically needs the range
timer feature that's aimed for 2.6.28), but I would much rather do that
in a different way: rather than actively moving stuff, I would instead
suggest sharing the timer queues between logical cpus that share the
same cache. (Now its an admin choice if he wants this on a "shared L1",
"shared L2" or "shared L3" basis). 

Or if you want to forcefully migrate timers, don't move existing ones,
just on queue/requeue put the on not-the-local-cpu. Sure they'll fire
once on the "wrong" cpu, but that's a very short term problem!

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  parent reply	other threads:[~2008-09-16 13:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-16  9:12 [RFC PATCH 0/1]: timers: Timer Migration Arun R Bharadwaj
2008-09-16 12:05 ` Peter Zijlstra
2008-09-16 16:47   ` Arun Bharadwaj
2008-09-17  7:35   ` Andrew Paprocki
2008-09-16 12:49 ` Andi Kleen
2008-09-16 13:53 ` Arjan van de Ven [this message]
2008-09-17  5:01   ` Arun R Bharadwaj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080916065345.76d052e1@infradead.org \
    --to=arjan@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=arun@linux.vnet.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=vatsa@linux.vnet.ibm.com \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox