From: Daniel J Blueman <daniel@numascale.com>
To: Oleg Nesterov <oleg@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Hillf Danton <dhillf@gmail.com>
Cc: Borislav Petkov <bp@amd64.org>, Ingo Molnar <mingo@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Steffen Persvold <sp@numascale.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [3.14] core onlining/hotplug regression
Date: Fri, 25 Jul 2014 15:50:06 +0800 [thread overview]
Message-ID: <53D20C2E.3070902@numascale.com> (raw)
Hi Thomas et al,
On a larger x86 system with 1728 cores, 3.15(.6) asserts on
smpboot_thread_fn's td->cpu != smp_processor_id() consistently after
~1500 cores are online.
Reverting the only directly related changes I could find [1,2] doesn't
help. Debugging indicates there is a race where the created thread is
quickly migrated to core 0 when this occurs, since smp_processor_id
returns 0 in these cases. Thomas introduced a thread parked state to fix
related issues a year back. Linux 3.14(.13) boots just nice.
Full boot output is at:
https://resources.numascale.com/linux-315-thread-mig.txt
Any theories so far? I'll start bisecting when I have full access to the
system again in a week and I'll do some more debugging with intermittent
access before then.
Thanks,
Daniel
-- [1]
commit 81c98869faa5f3a9457c93efef908ef476326b31
Author: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Date: Thu Apr 3 14:46:25 2014 -0700
kthread: ensure locality of task_struct allocations
-- [2]
commit 89f898c1e195fa6235c869bb457e500b7b3ac49d
Author: Igor Mammedov <imammedo@redhat.com>
Date: Thu Jun 5 15:42:43 2014 +0200
x86: Fix list/memory corruption on CPU hotplug
--
Daniel J Blueman
Principal Software Engineer, Numascale
next reply other threads:[~2014-07-25 8:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 7:50 Daniel J Blueman [this message]
2014-07-25 9:05 ` [3.14] core onlining/hotplug regression Thomas Gleixner
2014-07-25 9:36 ` Daniel J Blueman
2014-09-13 9:03 ` Daniel J Blueman
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=53D20C2E.3070902@numascale.com \
--to=daniel@numascale.com \
--cc=bp@amd64.org \
--cc=dhillf@gmail.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=sp@numascale.com \
--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 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.