linux-kernel - Re: [PATCH] Extend mwait idle to optimize away CAL and RES interrupts to an idle CPU -v1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Mar 2012 08:21:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Venki Pallipadi <venki@...gle.com>
Cc:	Suresh Siddha <suresh.b.siddha@...el.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


* Venki Pallipadi <venki@...gle.com> wrote:

> On Thu, Mar 1, 2012 at 5:37 PM, Suresh Siddha <suresh.b.siddha@...el.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@...el.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
--
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/