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:	Thu, 01 Mar 2012 17:28:52 -0800
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Venki Pallipadi <venki@...gle.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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 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.

thanks,
suresh

> Thanks,
> Venki
> 
> ---
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 66d250c..36b80ef 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -686,7 +686,7 @@ static int __cpuinit do_boot_cpu(int apicid, int cpu)
>                 .done   = COMPLETION_INITIALIZER_ONSTACK(c_idle.done),
>         };
> 
> -       INIT_WORK_ONSTACK(&c_idle.work, do_fork_idle);
> +       // INIT_WORK_ONSTACK(&c_idle.work, do_fork_idle);
> 
>         alternatives_smp_switch(1);
> 
> @@ -703,12 +703,13 @@ static int __cpuinit do_boot_cpu(int apicid, int cpu)
>                 goto do_rest;
>         }
> 
> -       schedule_work(&c_idle.work);
> -       wait_for_completion(&c_idle.done);
> +       // schedule_work(&c_idle.work);
> +       // wait_for_completion(&c_idle.done);
> +       c_idle.idle = fork_idle(cpu);
> 
>         if (IS_ERR(c_idle.idle)) {
>                 printk("failed fork for CPU %d\n", cpu);
> -               destroy_work_on_stack(&c_idle.work);
> +               // destroy_work_on_stack(&c_idle.work);
>                 return PTR_ERR(c_idle.idle);
>         }
> 
> @@ -831,7 +832,7 @@ do_rest:
>                 smpboot_restore_warm_reset_vector();
>         }
> 
> -       destroy_work_on_stack(&c_idle.work);
> +       // destroy_work_on_stack(&c_idle.work);
>         return boot_error;
>  }
> 
> ---
> 
> >
> > 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/