From: Valentin Schneider <valentin.schneider@arm.com>
To: peterz@infradead.org
Cc: mingo@kernel.org, vincent.guittot@linaro.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bristot@redhat.com, swood@redhat.com,
Vincent Donnefort <Vincent.Donnefort@arm.com>
Subject: Re: [PATCH 2/2] sched/hotplug: Ensure only per-cpu kthreads run during hotplug
Date: Fri, 11 Sep 2020 14:48:50 +0100 [thread overview]
Message-ID: <jhjo8mc5sql.mognet@arm.com> (raw)
In-Reply-To: <20200911122922.GJ1362448@hirez.programming.kicks-ass.net>
On 11/09/20 13:29, peterz@infradead.org wrote:
> On Fri, Sep 11, 2020 at 01:17:45PM +0100, Valentin Schneider wrote:
>
>> > @@ -6968,6 +7064,8 @@ int sched_cpu_deactivate(unsigned int cp
>> > */
>> > synchronize_rcu();
>> >
>> > + balance_push_set(cpu, true);
>> > +
>>
>> IIUC this is going to make every subsequent finish_lock_switch()
>> migrate the switched-to task if it isn't a pcpu kthread. So this is going
>> to lead to a dance of
>>
>> switch_to(<task0>) -> switch_to(<stopper>) -> switch_to(<task1>) -> switch_to(<stopper>) ...
>>
>> Wouldn't it be better to batch all those in a migrate_tasks() sibling that
>> skips pcpu kthreads?
>
> That's 'difficult', this is hotplug, performance is not a consideration.
>
Aye aye.
The reason I'm trying to care about this is (don't wince too hard) for that
CPU pause thing [1]. Vincent's been the one doing all the actual work so I
should let him pitch in, but TL;DR if we could "relatively quickly" migrate
all !pcpu tasks after clearing the active bit, we could stop hotplug there
and have our "CPU pause" thing.
[1]: https://lwn.net/Articles/820825/
> Basically we don't have an iterator for the runqueues, so finding these
> tasks is hard.
Mmph right, we'd pretty much have to "enjoy" iterating & skipping pcpu
threads every __pick_migrate_task() call...
next prev parent reply other threads:[~2020-09-11 16:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 8:17 [PATCH 0/2] sched: migrate_disable() preparations Peter Zijlstra
2020-09-11 8:17 ` [PATCH 1/2] sched: Fix balance_callback() Peter Zijlstra
2020-09-11 12:17 ` Valentin Schneider
2020-09-11 12:25 ` peterz
2020-09-11 13:27 ` Valentin Schneider
2020-09-11 8:17 ` [PATCH 2/2] sched/hotplug: Ensure only per-cpu kthreads run during hotplug Peter Zijlstra
2020-09-11 12:17 ` Valentin Schneider
2020-09-11 12:29 ` peterz
2020-09-11 13:48 ` Valentin Schneider [this message]
2020-09-16 10:18 ` Sebastian Andrzej Siewior
2020-09-16 12:10 ` peterz
2020-09-16 13:58 ` Sebastian Andrzej Siewior
2020-09-16 14:07 ` peterz
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=jhjo8mc5sql.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=Vincent.Donnefort@arm.com \
--cc=bristot@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=swood@redhat.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/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.