lkml.org 
[lkml]   [2008]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] sched: prevent bound kthreads from changing cpus_allowed


    Oleg Nesterov wrote:
    > On 06/10, Max Krasnyansky wrote:
    >> Peter Zijlstra wrote:
    >>> Per cpu workqueues should stay on their cpu.
    >>>
    >>> What you're really looking for is a more fine grained alternative to
    >>> flush_workqueue().
    >> Actually I had a discussion on that with Oleg Nesterov. If you remember my
    >> original solution (ie centralized cpu_isolate_map) was to completely redirect
    >> work onto other cpus. Then you pointed out that it's the flush_() that really
    >> makes the box stuck. So I started thinking about redoing the flush. While
    >> looking at the code I realized that if I only change the flush_() then queued
    >> work can get stale so to speak. ie Machine does not get stuck but some work
    >> submitted on the isolated cpus will sit there for a long time. Oleg pointed
    >> out exact same thing. So the simplest solution that does not require any
    >> surgery to the workqueue is to just move the threads to other cpus.
    >
    > Cough... I'd like to mention that I _personally agree with Peter, cwq->thread's
    > should stay on their cpu.
    I never argued against the _should stay_ ;-). What I'm arguing against is the
    _must stay_ which is a big difference. I'll start a separate thread on this.

    > I just meant that from the workqueue.c pov it is (afaics) OK to move cwq->thread
    > to other CPUs, in a sense that this shouldn't add races or hotplug problems, etc.
    Yep. That's what I was referring to in the explanation that I send to Peter.

    > But still this doesn't look right to me.
    Yeah, it's all about perceptions. We'll fix that ;-).

    Max



    \
     
     \ /
      Last update: 2008-06-10 20:01    [W:3.016 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site