All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	tglx@linutronix.de, bristot@redhat.com, yejune.deng@gmail.com
Subject: Re: [PATCH 1/2] sched: Make the idle task quack like a per-CPU kthread
Date: Tue, 11 May 2021 09:32:39 +0200	[thread overview]
Message-ID: <YJozF+wmiMYuSa6/@gmail.com> (raw)
In-Reply-To: <87k0o6int0.mognet@arm.com>


* Valentin Schneider <valentin.schneider@arm.com> wrote:

> On 10/05/21 16:10, Valentin Schneider wrote:
> > This requires some extra iffery as init_idle()
> > call be called more than once on the same idle task.
> >
> 
> While I'm at it, do we actually still need to suffer through this?

No.

> AFAICT the extra calls are due to idle_thread_get() (used in cpuhp) 
> calling init_idle(). However it looks to me that since
> 
>   3bb5d2ee396a ("smp, idle: Allocate idle thread for each possible cpu during boot")
> 
> we don't need to do that: we already have a
> 
>   for_each_possible_cpu(cpu)
>     init_idle(cpu)
> 
> issued at init. So can't we "simply" rely on that init-time creation, 
> given it's done against the possible mask? I think the only thing that 
> might need doing at later hotplug is making sure the preempt count is 
> right (secondary startups seem to all prepare the idle task by issuing a 
> preempt_disable()).

Best-case it works, worst-case we discover an unclean assumption in the 
init sequence and it works after we fix that.

Win-win. :-)

Thanks,

	Ingo

  reply	other threads:[~2021-05-11  7:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10 15:10 [PATCH 0/2] sched: Address idle task vs pcpu kthread checks Valentin Schneider
2021-05-10 15:10 ` [PATCH 1/2] sched: Make the idle task quack like a per-CPU kthread Valentin Schneider
2021-05-10 15:57   ` Valentin Schneider
2021-05-11  7:32     ` Ingo Molnar [this message]
2021-05-11  9:33       ` Valentin Schneider
2021-05-19  8:09   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2021-05-10 15:10 ` [PATCH 2/2] lib/smp_processor_id: Use is_percpu_thread() instead of nr_cpus_allowed Valentin Schneider
2021-05-19  8:09   ` [tip: sched/core] " tip-bot2 for Yejune Deng
2021-05-19  9:02   ` tip-bot2 for Yejune Deng
2021-05-31 10:21     ` [PATCH] sched,init: Fix DEBUG_PREEMPT vs early boot Peter Zijlstra
2021-06-01 11:54       ` Valentin Schneider
2021-06-01 14:04       ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-05-12 11:00 ` [PATCH 0/2] sched: Address idle task vs pcpu kthread checks Peter Zijlstra

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=YJozF+wmiMYuSa6/@gmail.com \
    --to=mingo@kernel.org \
    --cc=bristot@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    --cc=yejune.deng@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.