From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [rfc] forked kernel task and mm structures imbalanced on NUMA
Date: Tue, 01 Jun 2010 11:05:52 +0200 [thread overview]
Message-ID: <1275383152.27810.26387.camel@twins> (raw)
In-Reply-To: <20100601084157.GS9453@laptop>
On Tue, 2010-06-01 at 18:41 +1000, Nick Piggin wrote:
> > So I think it would make sense to rework the fork balancing muck to be
> > called only once and stick with its decision.
>
> Just need to close that race somehow. AFAIKS we can't use TASK_WAKING
> because that must not be preempted?
Right its basically a bit-spinlock and since it interacts with the
rq->lock it needs to have IRQs disabled while we have it set -- which
isn't a problem for the wakeup path, but it would be for the whole fork
path.
> > One thing that would make the whole fork path much easier is fully
> > ripping out that child_runs_first mess for CONFIG_SMP, I think its been
> > disabled by default for long enough, and its always been broken in the
> > face of fork balancing anyway.
>
> Interesting problem. vfork is nice for fork+exec, but it's a bit
> restrictive.
Right, and all that is a separate issue, its broken now, its still
broken with child_runs_first ripped out.
> > So basically we have to move fork balancing back to sched_fork(), I'd
> > have to again look at wth happens to ->cpus_allowed, but I guess it
> > should be fixable, and I don't think we should care overly much about
> > cpu-hotplug.
>
> No more than simply getting it right. Simply calling into the balancer
> again seems to be the simplest way to do it.
Right.
> > A specific code comment:
> >
> > > @@ -2550,14 +2561,16 @@ void wake_up_new_task(struct task_struct
> > > * We set TASK_WAKING so that select_task_rq() can drop rq->lock
> > > * without people poking at ->cpus_allowed.
> > > */
> > > - cpu = select_task_rq(rq, p, SD_BALANCE_FORK, 0);
> > > - set_task_cpu(p, cpu);
> > > -
> > > - p->state = TASK_RUNNING;
> > > - task_rq_unlock(rq, &flags);
> > > + if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) {
> > > + p->state = TASK_WAKING;
> > > + cpu = select_task_rq(rq, p, SD_BALANCE_FORK, 0);
> > > + set_task_cpu(p, cpu);
> > > + p->state = TASK_RUNNING;
> > > + task_rq_unlock(rq, &flags);
> > > + rq = task_rq_lock(p, &flags);
> > > + }
> > > #endif
> >
> > That's iffy because p->cpus_allowed isn't stable when we're not holding
> > the task's current rq->lock or p->state is not TASK_WAKING.
> >
>
> Oop, yeah missed that. Half hearted attempt to avoid more rq locks.
Yeah, something well worth the effort. At one point I considered making
p->cpus_allowed an RCU managed cpumask, but I never sat down and ran
through all the interesting races that that would bring.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [rfc] forked kernel task and mm structures imbalanced on NUMA
Date: Tue, 01 Jun 2010 11:05:52 +0200 [thread overview]
Message-ID: <1275383152.27810.26387.camel@twins> (raw)
In-Reply-To: <20100601084157.GS9453@laptop>
On Tue, 2010-06-01 at 18:41 +1000, Nick Piggin wrote:
> > So I think it would make sense to rework the fork balancing muck to be
> > called only once and stick with its decision.
>
> Just need to close that race somehow. AFAIKS we can't use TASK_WAKING
> because that must not be preempted?
Right its basically a bit-spinlock and since it interacts with the
rq->lock it needs to have IRQs disabled while we have it set -- which
isn't a problem for the wakeup path, but it would be for the whole fork
path.
> > One thing that would make the whole fork path much easier is fully
> > ripping out that child_runs_first mess for CONFIG_SMP, I think its been
> > disabled by default for long enough, and its always been broken in the
> > face of fork balancing anyway.
>
> Interesting problem. vfork is nice for fork+exec, but it's a bit
> restrictive.
Right, and all that is a separate issue, its broken now, its still
broken with child_runs_first ripped out.
> > So basically we have to move fork balancing back to sched_fork(), I'd
> > have to again look at wth happens to ->cpus_allowed, but I guess it
> > should be fixable, and I don't think we should care overly much about
> > cpu-hotplug.
>
> No more than simply getting it right. Simply calling into the balancer
> again seems to be the simplest way to do it.
Right.
> > A specific code comment:
> >
> > > @@ -2550,14 +2561,16 @@ void wake_up_new_task(struct task_struct
> > > * We set TASK_WAKING so that select_task_rq() can drop rq->lock
> > > * without people poking at ->cpus_allowed.
> > > */
> > > - cpu = select_task_rq(rq, p, SD_BALANCE_FORK, 0);
> > > - set_task_cpu(p, cpu);
> > > -
> > > - p->state = TASK_RUNNING;
> > > - task_rq_unlock(rq, &flags);
> > > + if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) {
> > > + p->state = TASK_WAKING;
> > > + cpu = select_task_rq(rq, p, SD_BALANCE_FORK, 0);
> > > + set_task_cpu(p, cpu);
> > > + p->state = TASK_RUNNING;
> > > + task_rq_unlock(rq, &flags);
> > > + rq = task_rq_lock(p, &flags);
> > > + }
> > > #endif
> >
> > That's iffy because p->cpus_allowed isn't stable when we're not holding
> > the task's current rq->lock or p->state is not TASK_WAKING.
> >
>
> Oop, yeah missed that. Half hearted attempt to avoid more rq locks.
Yeah, something well worth the effort. At one point I considered making
p->cpus_allowed an RCU managed cpumask, but I never sat down and ran
through all the interesting races that that would bring.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-06-01 9:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-01 7:33 [rfc] forked kernel task and mm structures imbalanced on NUMA Nick Piggin
2010-06-01 7:33 ` Nick Piggin
2010-06-01 8:16 ` Peter Zijlstra
2010-06-01 8:16 ` Peter Zijlstra
2010-06-01 8:41 ` Nick Piggin
2010-06-01 8:41 ` Nick Piggin
2010-06-01 9:05 ` Peter Zijlstra [this message]
2010-06-01 9:05 ` Peter Zijlstra
2010-06-01 8:49 ` Peter Zijlstra
2010-06-01 8:49 ` Peter Zijlstra
2010-06-01 15:48 ` Andi Kleen
2010-06-01 15:48 ` Andi Kleen
2010-06-01 15:59 ` Nick Piggin
2010-06-01 15:59 ` Nick Piggin
2010-06-01 16:20 ` Andi Kleen
2010-06-01 16:20 ` Andi Kleen
2010-06-01 16:31 ` Nick Piggin
2010-06-01 16:31 ` Nick Piggin
2010-06-01 16:00 ` Peter Zijlstra
2010-06-01 16:00 ` Peter Zijlstra
2010-06-01 16:02 ` Peter Zijlstra
2010-06-01 16:02 ` Peter Zijlstra
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=1275383152.27810.26387.camel@twins \
--to=peterz@infradead.org \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.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.