lkml.org 
[lkml]   [2004]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Performance regression in 2.6.7-rc3
    >> > How the hell can that have any effect on non-threaded workloads? Perhaps
    >> > some part of kernel compile *is* multi-threaded. It does seem to get
    >>
    >> make(1) with vfork(2) perhaps?
    >
    > Very likely. And in the vfork() case it is definitely WRONG to try to
    > reschedule (either threads _or_ processes), since the parent is going to
    > go to sleep real soon now.
    >
    > I think this code:
    >
    > if (clone_flags & CLONE_VM)
    > wake_up_forked_thread(p);
    > else
    > wake_up_forked_process(p);
    >
    > is just wrong, and it should be replaced with
    >
    > wake_up_new_process(p, clone_flags);
    >
    > and then "wake_up_new_process()" can do the right thing, which is
    > basically:
    >
    > if (clone_flags & CLONE_VFORK)
    > synchronous wakeup, same as pipe-will-block case
    > else if (clone_flags & CLONE_VM)
    > thread-wakeup-case
    > else
    > process-wakeup-case
    >
    > No?

    Looks much better ... but I'd still dispute whether we need to throw
    non-vfork threads cross node by default. I'd suggest that's disabled
    by default, and is either enabled by a global userspace option, or a
    per-process one (or the option of both). Most thing (except benchmarks)
    simply don't want this in real life ...

    M.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.029 / U:61.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site