Messages in this thread | | | Subject | Re: [RFC patch 2/5] smpboot: Provide infrastructure for percpu hotplug threads | From | Peter Zijlstra <> | Date | Fri, 15 Jun 2012 11:58:06 +0200 |
| |
On Fri, 2012-06-15 at 10:53 +0900, Tejun Heo wrote: > On Thu, Jun 14, 2012 at 10:17:28AM +0200, Peter Zijlstra wrote: > > On Thu, 2012-06-14 at 10:08 +0200, Peter Zijlstra wrote: > > > On Wed, 2012-06-13 at 20:56 +0200, Thomas Gleixner wrote: > > > > If it's just a spurious wakeup then it goes back to sleep right away > > > > as nothing cleared the park bit. > > > > > > Your spurious wakeup will have destroyed the binding though. So you need > > > to be careful. > > > > We should probably do something like the below.. > > > > TJ does this wreck workqueues? Its somewhat 'creative' in that regard > > and really wants fixing. > > > > --- > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -5018,6 +5018,8 @@ void do_set_cpus_allowed(struct task_str > > > > cpumask_copy(&p->cpus_allowed, new_mask); > > p->nr_cpus_allowed = cpumask_weight(new_mask); > > + if (p->nr_cpus_allowed != 1) > > + p->flags &= ~PF_THREAD_BOUND; > > The only reason wq workers use PF_THREAD_BOUND is to prevent userland > from mucking with cpus_allowed, so the above wouldn't break anything > in itself although userland would be able to wreck it afterwards.
Thing is, if things could get wrecked by userland moving a thread to a different cpu, things just got wrecked by the kernel doing that very same thing.
PF_THREAD_BOUND isn't called PF_NO_USER_AFFINITY (although it seems a popular interpretation).
| |