lkml.org 
[lkml]   [2010]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running
    * Ingo Molnar (mingo@elte.hu) wrote:
    >
    > * Mike Galbraith <efault@gmx.de> wrote:
    >
    > > On Sun, 2010-09-12 at 14:16 -0400, Mathieu Desnoyers wrote:
    >
    > > > Or am I missing your point ?
    > >
    > > Yes and no. I'm pondering the parent, but by the same token, the
    > > vfork child shouldn't be penalized either.
    > >
    > > Does your latency go down drastically if you turn START_DEBIT off?
    > > Seems like it should. Perhaps START_DEBIT should not start a task
    > > further right than rightmost. I've done that before.
    > >
    > > maximum latency: 19221.5 µs
    > > average latency: 5159.0 µs
    > > missed timer events: 0
    > >
    > > maximum latency: 43901.0 µs
    > > average latency: 8430.1 µs
    > > missed timer events: 0
    > >
    > > Turning it off here cut latency roughly in half (i've piddled vfork
    > > though, but not completely). Limiting child placement to no further
    > > right than rightmost should help quite a bit.
    >
    > Very interesting observation. Mathieu, mind testing Mike's suggestion
    > with wakeup-latency.c?

    Sure. this is with the smaller min_granularity:

    With START_DEBIT:

    maximum latency: 21111.1 µs
    average latency: 4188.2 µs
    missed timer events: 0

    Without:

    maximum latency: 6670.2 µs
    average latency: 1586.0 µs
    missed timer events: 0

    So yes, as expected, it makes a huge difference. This is because SIGEV_THREAD
    creates a new thread each time the timer fires, and newly created tasks are put
    at the end of the runqueue with START_DEBIT.

    However, removing START_DEBIT makes my Xorg feel less responsive (again, just my
    own impression). We might need a more suitable way to deal with forks than just
    putting the newly forked task at the end of the spread, but just putting it at
    the beginning of the spread does not seem to do well neither.

    One idea: we could temporarily tweak the nice value of both the parent and the
    child after a fork to a lower nice value, but only apply this for their first
    slice after the fork. The goal behind this is that their respective vruntime
    will increment faster in the first slice after the fork, so a fork bomb
    (worse-case) will end up running with a very very low nice level. With this
    measure in place, START_DEBIT might not be needed. Thoughts ?

    Thanks,

    Mathieu

    >
    > Thanks,
    >
    > Ingo

    --
    Mathieu Desnoyers
    Operating System Efficiency R&D Consultant
    EfficiOS Inc.
    http://www.efficios.com
    --
    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: 2010-09-13 22:21    [W:2.990 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site