All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: heiko.carstens@de.ibm.com, Tejun Heo <tj@kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] stop_machine: ensure that a queued callback will be called before cpu_stop_park()
Date: Thu, 15 Oct 2015 19:02:47 +0200	[thread overview]
Message-ID: <20151015170247.GA26019@redhat.com> (raw)
In-Reply-To: <20151014203245.GW3604@twins.programming.kicks-ass.net>

On 10/14, Peter Zijlstra wrote:
>
> On Wed, Oct 14, 2015 at 09:03:56PM +0200, Oleg Nesterov wrote:
> > On 10/14, Peter Zijlstra wrote:
> > >
> > > On Thu, Oct 08, 2015 at 04:51:31PM +0200, Oleg Nesterov wrote:
> > > >
> > > > Note also that smpboot_thread_call() calls cpu_stop_unpark() which
> > > > sets enabled == T at CPU_ONLINE stage, so this CPU can't go away until
> > > > cpu_stopper_thread() is called at least once. This all means that if
> > > > cpu_stop_queue_work() succeeds, we know that work->fn() will be called.
> > >
> > > This hard relies on the fact that cpu_down uses stop machine, right?
> >
> > Not really.
> >
> > > IIRC part of the hotplug rework Thomas is doing is geared towards
> > > breaking away from stop machine. There is nothing fundamental about
> > > hot-unplug that requires stop machine.
> >
> > cpu_down() should park/kill/whatever the percpu stopper thread anyway.
> > And this path should clear ->enabled, it can also flush the pending
> > works.
>
> So the proposed patch does: ->enabled=false; park();, which can race
> with if (->enabled) wake();

Yes, so I added the comment to explain that this is fine.

> smpboot_thread_fn() will not call ->thread_fn() when should_park(), and
> thus any pending work will not get flushed.
>
> It only works now because the stopper task calls park(), which means
> cpu_stopper_thread() will flush, but that very much relies on the
> stopper thread calling park in itself.

Yes. IOW, this relies on ->selfparking == T which implies "flush before
park".


But even if we change cpu_down() to avoid stop_machine() I think we need
to keep this "selfparking" logic. In a sense that, for example, this code

	void func(int cpu, cpu_stop_fn_t fn)
	{
		get_online_cpus();
		if (cpu_online(cpu) {
			int ret = stop_one_cpu(cpu, fn, NULL);
			BUG_ON(ret == -ENOENT);
		}
		put_online_cpus();
	}

should be correct. Actually this example is not very good, it would
be better to use stop_one_cpu_nowait() but currently it returns "void"
and hmm, it looks buggy ;) I'll send the fix on top of this series if
you accept it.

Oleg.


  reply	other threads:[~2015-10-15 17:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07  8:41 [RFC][PATCH] sched: Start stopper early Peter Zijlstra
2015-10-07 12:30 ` Oleg Nesterov
2015-10-07 12:38   ` Peter Zijlstra
2015-10-07 13:20     ` Oleg Nesterov
2015-10-07 13:24       ` Oleg Nesterov
2015-10-07 13:36       ` kbuild test robot
2015-10-08 14:50 ` [PATCH 0/3] (Was: [RFC][PATCH] sched: Start stopper early) Oleg Nesterov
2015-10-08 14:51   ` [PATCH 1/3] stop_machine: ensure that a queued callback will be called before cpu_stop_park() Oleg Nesterov
2015-10-14 15:34     ` Peter Zijlstra
2015-10-14 19:03       ` Oleg Nesterov
2015-10-14 20:32         ` Peter Zijlstra
2015-10-15 17:02           ` Oleg Nesterov [this message]
2015-10-16 10:49             ` Peter Zijlstra
2015-10-20  9:32     ` [tip:sched/core] stop_machine: Ensure " tip-bot for Oleg Nesterov
2015-10-08 14:51   ` [PATCH 2/3] stop_machine: introduce __cpu_stop_queue_work() and cpu_stop_queue_two_works() Oleg Nesterov
2015-10-20  9:33     ` [tip:sched/core] stop_machine: Introduce " tip-bot for Oleg Nesterov
2015-10-08 14:51   ` [PATCH 3/3] stop_machine: change cpu_stop_queue_two_works() to rely on stopper->enabled Oleg Nesterov
2015-10-08 15:04     ` Peter Zijlstra
2015-10-08 15:59       ` Oleg Nesterov
2015-10-08 16:08         ` Oleg Nesterov
2015-10-08 17:01     ` [PATCH v2 " Oleg Nesterov
2015-10-09 16:37       ` Peter Zijlstra
2015-10-09 16:40         ` Oleg Nesterov
2015-10-20  9:33       ` [tip:sched/core] stop_machine: Change " tip-bot for Oleg Nesterov
2015-10-08 18:05 ` [RFC][PATCH] sched: Start stopper early Oleg Nesterov
2015-10-08 18:47   ` Oleg Nesterov
2015-10-09 16:00 ` [PATCH 0/3] make stopper threads more "selfparking" Oleg Nesterov
2015-10-09 16:00   ` [PATCH 1/3] stop_machine: kill smp_hotplug_thread->pre_unpark, introduce stop_machine_unpark() Oleg Nesterov
2015-10-20  9:33     ` [tip:sched/core] stop_machine: Kill smp_hotplug_thread-> pre_unpark, " tip-bot for Oleg Nesterov
2015-10-09 16:00   ` [PATCH 2/3] stop_machine: kill cpu_stop_threads->setup() and cpu_stop_unpark() Oleg Nesterov
2015-10-20  9:34     ` [tip:sched/core] stop_machine: Kill " tip-bot for Oleg Nesterov
2015-10-09 16:00   ` [PATCH 3/3] sched: start stopper early Oleg Nesterov
2015-10-09 16:49     ` Oleg Nesterov
2015-10-20  9:34     ` [tip:sched/core] sched: Start " tip-bot for Peter Zijlstra
2015-10-16  8:22 ` [RFC][PATCH] " Heiko Carstens
2015-10-16  9:57   ` Peter Zijlstra
2015-10-16 12:01     ` Heiko Carstens
2015-10-26 14:24       ` Michael Holzheu
2015-10-26 20:20         ` 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=20151015170247.GA26019@redhat.com \
    --to=oleg@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.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.