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    [from the cache]
©2003-2011 Jasper Spaans