lkml.org 
[lkml]   [2010]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] perf_events: improve x86 event scheduling (v5)
    From
    2010/1/19 Peter Zijlstra <peterz@infradead.org>:
    > On Tue, 2010-01-19 at 16:55 +0100, Frederic Weisbecker wrote:
    >> > Also, I see you set an ->unthrottle, but then don't implement it, but
    >> > comment it as todo, which is strange because that implies its broken. If
    >> > there's an ->unthrottle method it will throttle, so if its todo, the
    >> > safest thing is to not set it.
    >>
    >>
    >> Yeah, that's because I have a too vague idea on what is the purpose
    >> of the unthrottle() callback.
    >>
    >> I've read the concerned codes that call this, several times, and I still
    >> can't figure out what happens there, not sure what is meant by throttle
    >> or unthrottle there :-/
    >
    > OK, so not setting it is relatively safe.
    >
    > As to what it does, it has to undo everything you do when
    > perf_event_overflow() returns true, which happens when ->unthrottle is
    > set and we get more than sysctl_perf_event_sample_rate/HZ events in a
    > jiffy.
    >
    > If you look at the x86 implementation, you'll see that we simply disable
    > the hardware counter when the overflow call returns true, so the
    > unthrottle() callback simply enables it again.


    Ok, I understand better now what mean "throttle" and "unthrottle" here.

    But looking at what happens when we reach an event storm point, the
    pending and subsequent
    overflows until the next tick are just cancelled and that's it (as
    it's using the software overflow
    handler, not the x86 one). So we throttle and it's what we would want
    to avoid a hang. If I remove my
    unthrottle stub, it won't throttle anymore.

    Theorically, the best would be to implement a true unthrottle
    callback, which would just clear dr7,
    really trivial. But I don't like this as ptrace events must always be
    reported. A userspace app
    could be polling a watchpointed variable, causing a lot of events, may
    be that could trigger
    a storm and then perf would throttle. Sure this is not supposed to
    happen, given the fact ptrace breakpoints
    are signaled to a debugger, which reduces the possible storm windows.
    But just imagine a silly user sets sysctl_perf_event_sample_rate to 1,
    then we would throttle at
    each events, breaking the ptrace determinism rules.

    So for now, I guess I need to remove my unthrottle stub, breakpoints
    don't want to throttle because
    of the ptrace determinism requirements.


    \
     
     \ /
      Last update: 2010-02-27 18:41    [W:0.046 / U:267.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site