lkml.org 
[lkml]   [2010]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 34/35] async: use workqueue for worker pool
    Hello,

    On 06/29/2010 08:41 PM, Arjan van de Ven wrote:
    >> Well, the thing is, for most cases, binding to cpus is simply better.
    >
    > depends on the user.

    Heh, yeah, sure, can't disagree with that. :-)

    > For "throw over the wall" work, this is unclear. Especially in the
    > light of hyperthreading (sharing L1 cache) or even modern cpus
    > (where many cores share a fast L3 cache).

    There will be many variants of memory configurations and the only way
    the generic kernel can optimize memory access is if it localizes stuff
    per cpu which is visible to the operating system. That's the lowest
    common denominator. From there, we sure can add considerations for
    specific shared configurations but I don't think that will be too
    common outside of scheduler and maybe memory allocator. It just
    becomes too specific to apply to generic kernel core code.

    > I'm fine with a solution that has the caller say 'run anywhere' vs
    > 'try to run local'. I suspect there will be many many cases of 'run
    > anywhere'.isn't hard at all. I just wanna know whether it's
    > something which is

    Yeah, sure. I can almost view the code in my head right now. If I'm
    not completely mistaken, it should be really easy. When a cpu goes
    down, all the left works are already executed unbound, so all the
    necessary components are already there.

    The thing is that once it's not bound to a cpu, where, how and when a
    worker runs is best regulated by the scheduler. That's why I kept
    talking about wq being simple context provider.

    If something is not CPU intensive, CPU parallelism doesn't buy much,
    so works which would benefit from parallel execution are likely to be
    CPU intensive ones. For CPU intensive tasks, fairness, priority and
    all that stuff are pretty important and that's scheduler's job. cmwq
    can provide contexts and put some safety limitations but most are best
    left to the scheduler.

    >> actually useful. So, where would that be useful?
    >
    > I think it's useful for all users of your worker pool, not (just) async.
    >
    > it's a severe limitation of the current linux infrastructure, and your
    > infrastructure has the chance to fix this...

    Yeah, there could be situations where having a generic context
    provider can be useful. I'm just not sure async falls in that
    category. For the current users, I think we would be (marginally)
    better off with bound workers. So, that's the reluctance I have about
    updating async conversion.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2010-06-29 21:03    [W:3.589 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site