From: Steven Rostedt <rostedt@goodmis.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Clark Williams <clark.williams@gmail.com>
Subject: Re: [PATCH RT 7/9][RFC] [PATCH 7/9] cpu/rt: Rework cpu down for PREEMPT_RT
Date: Fri, 02 Mar 2012 10:11:52 -0500 [thread overview]
Message-ID: <1330701112.25686.257.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1203021518501.2742@ionos>
On Fri, 2012-03-02 at 15:52 +0100, Thomas Gleixner wrote:
> On Thu, 1 Mar 2012, Steven Rostedt wrote:
> > Bringing a CPU down is a pain with the PREEMPT_RT kernel because
> > tasks can be preempted in many more places than in non-RT. In
> > order to handle per_cpu variables, tasks may be pinned to a CPU
> > for a while, and even sleep. But these tasks need to be off the CPU
> > if that CPU is going down.
> >
> > Several synchronization methods have been tried, but when stressed
> > they failed. This is a new approach.
>
> OMG! That hotplug stuff has been ugly as hell already, but you managed
> to make it exponentially worse. That's really an achievement.
*Blush* Oh no, I don't deserve the credit for that. Adding the
migrate_disable() and friends in -rt did most the work for me.
>
> Instead of adding more mess, we should simply fix hotplug.
>
> We can migrate away all tasks _before_ we run stomp-machine and
Well, that's what this patch pretty much tried to do. But I agree, not
so nicely.
Should we call into the scheduler and tell it to do the migrate all
tasks off and add no new ones? But note, the migrate is done with
stomp_machine too. (per cpu, and on the CPU that's going down). Then we
need to let the scheduler allow stomp_machine to enter the CPU, which
shouldn't be that hard.
> prevent that any new tasks go on the cpu which is about to be taken
> down. Once all migratable tasks are gone, we only have to deal with
> the cpu bound ones, which is not causing such headaches.
Also, the headaches came mostly from the tasks that were bound to the
CPU. Moving everything off after the notifiers is what's best. I may be
able to have that happen. We need a way to call into the scheduler and
tell it to migrate everything off then.
>
> So no, I rather keep the current problem than applying that insanity.
Note, the sync daemon was already added in -rt, I just modified it to be
a little different. What is currently there introduced lots of races
(especially that grabbing of the mutex). And is completely broken.
I'm willing to take another shot at it, but I'm burnt out from this
hotplug crap and I'm way behind in my other duties because of it. As for
now we have a fix (yes it's crappy), for those that need hotplug
working, they can use this mess.
I'm going to go off and catch up on my other work and when I get time
again I'll take another shot at it. Unless someone else beats me to it
(I can only hope so).
-- Steve
next prev parent reply other threads:[~2012-03-02 15:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 18:55 [PATCH RT 0/9][RFC] rt: Fix hotplugging and other nasties Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 1/9][RFC] [PATCH 1/9] timer: Fix hotplug for -rt Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 2/9][RFC] [PATCH 2/9] futex/rt: Fix possible lockup when taking pi_lock in proxy handler Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 3/9][RFC] [PATCH 3/9] lglock/rt: Use non-rt for_each_cpu() in -rt code Steven Rostedt
2012-03-02 7:25 ` Srivatsa S. Bhat
2012-03-02 14:20 ` Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 4/9][RFC] [PATCH 4/9] rtmutex: Add new mutex_lock_savestate() API Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 5/9][RFC] [PATCH 5/9] ring-buffer/rt: Check for irqs disabled before grabbing reader lock Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 6/9][RFC] [PATCH 6/9] sched/rt: Fix wait_task_interactive() to test rt_spin_lock state Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 7/9][RFC] [PATCH 7/9] cpu/rt: Rework cpu down for PREEMPT_RT Steven Rostedt
2012-03-02 14:52 ` Thomas Gleixner
2012-03-02 15:11 ` Steven Rostedt [this message]
2012-03-02 15:15 ` Steven Rostedt
2012-03-02 15:20 ` Thomas Gleixner
2012-03-02 15:36 ` Steven Rostedt
2012-03-02 15:39 ` Steven Rostedt
2012-03-02 15:40 ` Steven Rostedt
2012-03-02 15:51 ` Thomas Gleixner
2012-03-01 18:55 ` [PATCH RT 8/9][RFC] [PATCH 8/9] workqueue: Revert workqueue: Fix PF_THREAD_BOUND abuse Steven Rostedt
2012-03-01 18:55 ` [PATCH RT 9/9][RFC] [PATCH 9/9] workqueue: Revert workqueue: Fix cpuhotplug trainwreck Steven Rostedt
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=1330701112.25686.257.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=C.Emde@osadl.org \
--cc=clark.williams@gmail.com \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®