From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ming Lei <tom.leiming@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning
Date: Wed, 17 Aug 2016 00:19:53 +0200 [thread overview]
Message-ID: <20160816221953.GA3373@osiris> (raw)
In-Reply-To: <20160816154205.GE9516@htj.duckdns.org>
On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote:
> > > As long as the mapping doesn't change after the first onlining of the
> > > CPU, the workqueue side shouldn't be too difficult to fix up. I'll
> > > look into it. For memory allocations, as long as the cpu <-> node
> > > mapping is established before any memory allocation for the cpu takes
> > > place, it should be fine too, I think.
> >
> > Don't we allocate per-cpu memory for 'cpu_possible_map' on boot? There's
> > a whole bunch of per-cpu memory users that does things like:
> >
> >
> > for_each_possible_cpu(cpu) {
> > struct foo *foo = per_cpu_ptr(&per_cpu_var, cpu);
> >
> > /* muck with foo */
> > }
> >
> >
> > Which requires a cpu->node map for all possible cpus at boot time.
>
> Ah, right. If cpu -> node mapping is dynamic, there isn't much that
> we can do about allocating per-cpu memory on the wrong node. And it
> is problematic that percpu allocations can race against an onlining
> CPU switching its node association.
>
> One way to keep the mapping stable would be reserving per-node
> possible CPU slots so that the CPU number assigned to a new CPU is on
> the right node. It'd be a simple solution but would get really
> expensive with increasing number of nodes.
>
> Heiko, do you have any ideas?
I think the easiest solution would be to simply assign all cpus, for which
we do not have any topology information, to an arbitrary node; e.g. round
robin.
After all the case that cpus are added later is rare and the s390 fake numa
implementation does not know about the memory topology. All it is doing is
distributing the memory to several nodes in order to avoid a single huge
node. So that should be sort of ok.
Unless somebody has a better idea?
Michael, Martin?
next prev parent reply other threads:[~2016-08-16 22:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 12:54 [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning Heiko Carstens
2016-07-27 15:23 ` Thomas Gleixner
2016-07-30 11:25 ` Heiko Carstens
2016-08-08 7:45 ` Ming Lei
2016-08-15 11:19 ` Heiko Carstens
2016-08-15 22:48 ` Tejun Heo
2016-08-16 7:55 ` Heiko Carstens
2016-08-16 15:20 ` Tejun Heo
2016-08-16 15:29 ` Peter Zijlstra
2016-08-16 15:42 ` Tejun Heo
2016-08-16 22:19 ` Heiko Carstens [this message]
2016-08-17 9:20 ` Michael Holzheu
2016-08-17 13:58 ` Tejun Heo
2016-08-18 9:30 ` Michael Holzheu
2016-08-18 14:42 ` Tejun Heo
2016-08-19 9:52 ` Michael Holzheu
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=20160816221953.GA3373@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=holzheu@linux.vnet.ibm.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=tom.leiming@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox