From: Ingo Molnar <mingo@elte.hu>
To: Venki Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Aaron Durbin <adurbin@google.com>, Paul Turner <pjt@google.com>,
Yong Zhang <yong.zhang0@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Extend mwait idle to optimize away CAL and RES interrupts to an idle CPU -v1
Date: Fri, 2 Mar 2012 08:21:47 +0100 [thread overview]
Message-ID: <20120302072147.GA32401@elte.hu> (raw)
In-Reply-To: <CABeCy1a7RszUWBV10tVbdsxAdPpQAMSQXw-pMG2znTqYb5WN5A@mail.gmail.com>
* Venki Pallipadi <venki@google.com> wrote:
> On Thu, Mar 1, 2012 at 5:37 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> > On Thu, 2012-03-01 at 17:35 -0800, Venki Pallipadi wrote:
> >> On Thu, Mar 1, 2012 at 5:28 PM, Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> >> > On Thu, 2012-03-01 at 16:33 -0800, Venki Pallipadi wrote:
> >> >> >
> >> >> > fork_idle() should also make sure it does not schedule the child
> >> >> > thread: thus we'd also be able to further simplify smpboot.c and
> >> >> > get rid of all that extremely ugly 'struct create_idle'
> >> >> > gymnastics in smpboot.c.
> >> >>
> >> >> But not this. I am not sure where fork_idle results in resched of the child.
> >> >> As I saw it, fork_idle calls init_idle and that sets the affinity of
> >> >> idle_task to target CPU. So, reschedule should not be a problem. What
> >> >> am I missing here?
> >> >
> >> > I think Ingo is referring to the fact that we can't use kthread_create()
> >> > here and hence we were relying on fork_idle().
> >> >
> >> >> Also, I tried this silly test patch (Cut and paste... Sorry) and it
> >> >> seemed to work fine both with and without CPU hotplug.
> >> >>
> >> >
> >> > I don't think we can do this today, as we need to make
> >> > sure we have the correct current context. With dynamic
> >> > cpu hotplug, current context can be any process and hence
> >> > we were depending on the schedule_work() context.
> >>
> >> schedule_work() is only done at boot time. In case of
> >> dynamic cpu hotplug, we skip the whole fork_idle as we
> >> already have the task struct and just do init_idle().
> >>
> >
> > What happens if we boot with "maxcpus=" and later online the
> > remaining cpu's?
>
> 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?
Thanks,
Ingo
next prev parent reply other threads:[~2012-03-02 7:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 0:36 [PATCH] Extend mwait idle to optimize away CAL and RES interrupts to an idle CPU -v1 Venkatesh Pallipadi
2012-02-23 7:50 ` Ingo Molnar
2012-02-23 9:08 ` Peter Zijlstra
2012-02-23 20:04 ` Venki Pallipadi
2012-02-23 20:03 ` Venki Pallipadi
2012-03-02 0:33 ` Venki Pallipadi
2012-03-02 1:28 ` Suresh Siddha
2012-03-02 1:35 ` Venki Pallipadi
2012-03-02 1:37 ` Suresh Siddha
2012-03-02 2:00 ` Venki Pallipadi
2012-03-02 7:21 ` Ingo Molnar [this message]
2012-03-02 17:41 ` Suresh Siddha
2012-03-06 21:41 ` fork_idle from wq cleanup Venkatesh Pallipadi
2012-03-06 21:41 ` [PATCH 1/5] x86: Move fork_idle from wq and idle caching to common code Venkatesh Pallipadi
2012-03-06 21:41 ` [PATCH 2/5] ia64: Use common fork_idle_from_wq in smpboot Venkatesh Pallipadi
2012-03-06 21:41 ` [PATCH 3/5] mips: " Venkatesh Pallipadi
2012-03-06 22:51 ` Ralf Baechle
2012-03-06 21:41 ` [PATCH 4/5] powerpc: " Venkatesh Pallipadi
2012-03-06 21:41 ` [PATCH 5/5] s390: " Venkatesh Pallipadi
2012-03-07 7:00 ` Heiko Carstens
2012-03-07 6:06 ` fork_idle from wq cleanup Suresh Siddha
2012-02-23 9:30 ` [PATCH] Extend mwait idle to optimize away CAL and RES interrupts to an idle CPU -v1 Peter Zijlstra
2012-02-23 19:34 ` Venki Pallipadi
2012-02-24 5:41 ` Yong Zhang
2012-02-24 6:13 ` Yong Zhang
2012-02-27 8:38 ` Peter Zijlstra
2012-02-27 9:08 ` Yong Zhang
2012-02-27 9:30 ` Peter Zijlstra
2012-02-27 9:51 ` Yong Zhang
2012-02-26 1:32 ` Paul E. McKenney
2012-02-27 9:06 ` Yong Zhang
2012-02-27 17:05 ` Paul E. McKenney
2012-02-28 7:12 ` Yong Zhang
2012-02-28 13:05 ` Paul E. McKenney
2012-02-29 6:36 ` Yong Zhang
2012-02-27 8:45 ` Peter Zijlstra
2012-02-27 18:17 ` Venki Pallipadi
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=20120302072147.GA32401@elte.hu \
--to=mingo@elte.hu \
--cc=adurbin@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venki@google.com \
--cc=yong.zhang0@gmail.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;
as well as URLs for NNTP newsgroup(s).