From: Oleg Nesterov <oleg@redhat.com>
To: Don Zickus <dzickus@redhat.com>
Cc: Aaron Tomlin <atomlin@redhat.com>,
mingo@redhat.com, mingo@kernel.com, linux-kernel@vger.kernel.org
Subject: [PATCH 1/4 v2] nmi: Provide the option to issue an NMI back trace to every cpu but current
Date: Mon, 21 Apr 2014 15:41:54 +0200 [thread overview]
Message-ID: <20140421134154.GA13766@redhat.com> (raw)
In-Reply-To: <20140421132100.GW8488@redhat.com>
On 04/21, Don Zickus wrote:
>
> On Tue, Apr 15, 2014 at 07:26:49PM +0200, Oleg Nesterov wrote:
> > On 04/15, Oleg Nesterov wrote:
> > >
> > > Looking at https://lkml.org/lkml/2014/4/4/469... It seems that 2/4 can be
> > > simplified, you can simply remove smp_processor_id() from backtrace_mask
> > > if !include_self and use apic->send_IPI_mask(backtrace_mask). But this is
> > > minor, I won't insist.
> >
> > And in fact, I do not understand why arch_trigger_all_cpu_backtrace() doesn't
> > disable preemption. OK, probably we can simply ignore the race with cpu hotplug.
> >
> > But it seems that your patch makes the things worse. Lets look at, say,
> > numachip_send_IPI_mask_allbutself(). The usage of smp_processor_id() is
> > obviously racy but perhaps we do not care again. But we do not want a warning
> > from debug_smp_processor_id().
>
> Good point. I forgot that going from all cpus down to allbutself,
> preemption now matters.
I am not sure it actually matters wrt "show other CPU's traces". If the preemption
is possible then the caller can be preempted even before it sends ipi.
OTOH I think it does matter anyway, even without your patch, otherwise the usage
of cpu_online_mask is racy and we can hit the "Wait for up to 10 seconds" case.
Btw...
/* Wait for up to 10 seconds for all CPUs to do the backtrace */
for (i = 0; i < 10 * 1000; i++) {
if (cpumask_empty(to_cpumask(backtrace_mask)))
break;
mdelay(1);
}
OK, but perhaps we should clear backtrace_mask if we return due to timeout.
> does disabling preemption help in the cpu
> hotplug case?
Yes. But I'd suggest to change your patch to use get_cpu() instead of
preempt_disable/smp_processor_id.
And I think it would be better to not discuss this off-list, I added lkml.
Oleg.
next parent reply other threads:[~2014-04-21 13:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140415075650.GG2195@atomlin.usersys.redhat.com>
[not found] ` <20140415170202.GA7948@redhat.com>
[not found] ` <20140415172649.GA10152@redhat.com>
[not found] ` <20140421132100.GW8488@redhat.com>
2014-04-21 13:41 ` Oleg Nesterov [this message]
2014-04-21 15:47 ` [PATCH 1/4 v2] nmi: Provide the option to issue an NMI back trace to every cpu but current Don Zickus
2014-04-04 20:47 [PATCH 0/4 V2] Print traces on softlockups Don Zickus
2014-04-04 20:47 ` [PATCH 1/4 v2] nmi: Provide the option to issue an NMI back trace to every cpu but current Don Zickus
2014-04-04 20:47 ` Don Zickus
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=20140421134154.GA13766@redhat.com \
--to=oleg@redhat.com \
--cc=atomlin@redhat.com \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.com \
--cc=mingo@redhat.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.