lkml.org 
[lkml]   [2012]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC patch 2/5] smpboot: Provide infrastructure for percpu hotplug threads
    From
    Date
    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).




    \
     
     \ /
      Last update: 2012-06-15 12:41    [W:4.169 / U:0.664 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site