[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1330710103.30167.84.camel@sbsiddha-desk.sc.intel.com>
Date: Fri, 02 Mar 2012 09:41:43 -0800
From: Suresh Siddha <suresh.b.siddha@...el.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Venki Pallipadi <venki@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Aaron Durbin <adurbin@...gle.com>,
Paul Turner <pjt@...gle.com>,
Yong Zhang <yong.zhang0@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Extend mwait idle to optimize away CAL and RES
interrupts to an idle CPU -v1
On Fri, 2012-03-02 at 08:21 +0100, Ingo Molnar wrote:
> * Venki Pallipadi <venki@...gle.com> wrote:
> > Yes. This case will be problematic. So, we still need struct
> > create_idle work stuff even after percpu idle_task. Or was
> > Ingo's suggestion to do something along the lines of - init
> > any CPU's idle task from CPU 0's idle task?
>
> If the percpu area of possible CPUs is already allocated at this
> point then we should probably do that.
>
> If not then what is the problem with doing fork_idle() from the
> hotplug process context? Where does the assymetry in the dynamic
> case come from?
As far as I know, we limit the # of cpus that can be onlined to the
possible cpus determined at boot time and this doesn't change after
boot. percpu area of possible cpu's already allocated by this point.
Main exercise I think is to move the init_task to percpu area of cpu-0
and ensure that fork_idle() does the init properly (with out allocating
the memory but do the initialization done by the
copy_process/dup_task_struct etc)
thanks,
suresh
--
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