[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090226085831.GA28397@in.ibm.com>
Date: Thu, 26 Feb 2009 14:28:31 +0530
From: Dipankar Sarma <dipankar@...ibm.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
a.p.zijlstra@...llo.nl, ego@...ibm.com, tglx@...utronix.de,
andi@...stfloor.org, venkatesh.pallipadi@...el.com,
vatsa@...ux.vnet.ibm.com, arun@...ux.vnet.ibm.com,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [RFC PATCH 0/4] timers: framework for migration between CPU
On Mon, Feb 23, 2009 at 12:07:25PM +0100, Ingo Molnar wrote:
>
> * Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com> wrote:
>
> > * Identify set of idle CPUs (CPU package) from which timers
> > can be removed
> > * Identify a semi-idle or idle CPU package to which the timers
> > can be moved
> > * Decide when to start moving timers as the system has large
> > number of idle CPUs
> > * Decide when to stop migrating as system becomes less idle
> > and utilisation increases
> >
> > Guiding all of the above decisions from user space may not be
> > fast enough.
>
> Exactly.
That is true for power management. However there are other
situations where we may need targeted avoidance of timers.
Certain type of applications - HPC for example - prefer avoidance
of jitters due to periodic timers. It would be good to be
able to say "avoid these CPUs for timers" while they are being
used for HPC tasks.
Thanks
Dipankar
--
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