lkml.org 
[lkml]   [2009]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: workqueue thing
    Hello,

    On 12/22/2009 12:19 AM, Arjan van de Ven wrote:
    > On 12/21/2009 15:19, Tejun Heo wrote:
    >>
    >> Ah... okay, there are two aspects cmwq invovles the scheduler.
    >>
    >> A. Concurrency management. This is achieved by the scheduler
    >> callbacks which watches how many workers are working.
    >>
    >> B. Deadlock avoidance. This requires migrating rescuers to CPUs under
    >> allocation distress. The problem here is that
    >> set_cpus_allowed_ptr() doesn't allow migrating tasks to CPUs which
    >> are online but !active (CPU_DOWN_PREPARE).
    >
    > why would you get involved in what-runs-where at all? Wouldn't the
    > scheduler load balancer be a useful thing ? ;-)

    That's the way workqueues have been designed and used because its
    primary purpose is to supply sleepable context and for that crossing
    cpu boundaries is unnecessary overhead, so many of its users wouldn't
    benefit from load balancing and some of them assume strong CPU
    affinity. cmwq's goal is to improve workqueues. If you want to
    implement something which would take advantage of processing
    parallelism, it would need to be a separate mechanism (which may share
    the API via out-of-range CPU affinty or something but still a separate
    mechanism).

    >> For A, it's far more efficient and robust with scheduler callbacks.
    >> It's conceptually pretty simple too.
    >
    > Assuming you don't get tasks that do lots of cpu intense work and
    > that need to get preempted etc...like raid5/6 sync but also the
    > btrfs checksumming etc etc. That to me is the weak spot of the
    > scheduler callback thing. We already have a whole thing that knows
    > how to load balance and preempt tasks... it's called "scheduler".
    > Let the scheduler do its job and just give it insight in the work
    > (by having a runnable thread)

    Yeah, sure, it's not suited for offloading CPU intensive workloads
    (checksumming and encryption basically). Workqueue interface was
    never meant to be used by them - it has strong cpu affinity. We need
    something which is more parallelism aware for those.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2009-12-22 01:01    [W:4.040 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site