From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>
Cc: Daniel Wagner <wagi@monom.org>,
linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Null pointer 4.14.1-rt3
Date: Fri, 1 Dec 2017 13:26:05 +0100 [thread overview]
Message-ID: <20171201122605.GD1612@linutronix.de> (raw)
In-Reply-To: <20171130113533.4485d894@gandalf.local.home>
On 2017-11-30 11:35:33 [-0500], Steven Rostedt wrote:
> Hmm, I'm not sure I tested this on a UP machine. Perhaps I should boot
> with CPUs=1
It does not crash everywhere. For instance Dra7x, imx6 do not crash
because they have GICv3 which does set required SMP function even on UP
systems. BBB which uses the ti,am33xx-intc / INTC does not and here we
boom.
>From what I see (in qemu) it won't explode on a x86-SMP config with one
CPU either because it sets that function, too (on APIC).
For RT it is enough to start one cyclictest. For !RT it looks to be
enough to enable SW-Watchdog and RCU boosting and I see
pull_rt_task() -> tell_cpu_to_push -> irq_work_queue_on()
on v4.14.2 with "sched/rt: Simplify the IPI based RT balancing logic"
Now, what do we do about it?
- does it make sense to tell tell_cpu_to_push() to not do anything if
the target CPU is the same as the current?
- irq_work_queue() uses arch_irq_work_raise() which has a check (on ARM)
and uses it only if it is really on SMP. The other user of
arch_send_call_function_single_ipi() is generic_exec_single() and this
one skips the invocation if target CPU == current CPU and invokes the
function directly. We could invoke arch_irq_work_raise() instead for
"local" case.
- disable RT_PUSH_IPI if booted on UP. After all there is not much
benefit here, is there?
- make a requirement for working arch_send_call_function_single_ipi()
but I guess invoking code for no reason make no sense.
Sebastian
next prev parent reply other threads:[~2017-12-01 12:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 14:42 Null pointer 4.14.1-rt3 Daniel Wagner
2017-11-30 15:11 ` Daniel Wagner
2017-11-30 15:29 ` Sebastian Andrzej Siewior
2017-11-30 16:22 ` Steven Rostedt
2017-11-30 16:24 ` Sebastian Andrzej Siewior
2017-11-30 16:35 ` Steven Rostedt
2017-12-01 12:26 ` Sebastian Andrzej Siewior [this message]
2017-12-01 16:03 ` Steven Rostedt
2017-12-01 16:38 ` Sebastian Andrzej Siewior
2017-11-30 15:42 ` Sebastian Andrzej Siewior
2017-12-01 7:12 ` Daniel Wagner
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=20171201122605.GD1612@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=wagi@monom.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.