Re: [PATCH] sched: don't wait in kthread_bind for presmp initcalls

[Xie XiuQi]

On 2013/7/30 1:19, Abbas Raza wrote:
> From: Abbas Raza <Abbas_Raza@xxxxxxxxxx>
> 
> wait_task_inactive shouldn't be called in kthread_bind for presmp
> initcalls the same way it is done in !SMP case.
> 
> more info here:
> http://permalink.gmane.org/gmane.linux.kernel.embedded/4046
> 
> This patch improves boot time for pre-smp initcalls as given below
> 
> initcall spawn_ksoftirqd+0x0/0x54 returned 0 after 0 usecs
> initcall init_workqueues+0x0/0x358 returned 0 after 0 usecs
> initcall cpu_stop_init+0x0/0xcc returned 0 after 0 usecs
> 
> boot time without this patch:
> 
> initcall spawn_ksoftirqd+0x0/0x54 returned 0 after 9765 usecs
> initcall init_workqueues+0x0/0x358 returned 0 after 9765 usecs
> initcall cpu_stop_init+0x0/0xcc returned 0 after 19531 usecs
> 
> Signed-off-by: Abbas Raza <Abbas_Raza@xxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> 
> ---
>  kernel/kthread.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index b579af5..80f19b5 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -221,10 +221,15 @@ EXPORT_SYMBOL(kthread_create_on_node);
>   */
>  void kthread_bind(struct task_struct *p, unsigned int cpu)
>  {
> -	/* Must have done schedule() in kthread() before we set_task_cpu */
> -	if (!wait_task_inactive(p, TASK_UNINTERRUPTIBLE)) {
> -		WARN_ON(1);
> -		return;

Hi Abbas, this patch isn't based the current mainline, and kthread_bind()
has been changed since v3.9.

> +	if (!((num_online_cpus() == 1) && !cpu)) {
> +		/*
> +		 * Must have done schedule() in kthread() before
> +		 * we set_task_cpu
> +		 */
> +		if (!wait_task_inactive(p, TASK_UNINTERRUPTIBLE)) {
> +			WARN_ON(1);
> +			return;
> +		}
>  	}
>  
>  	/* It's safe because the task is inactive. */
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/