linux-kernel - Re: [PATCH] perf_events: improve x86 event scheduling (v5)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c62985531002270938k472c1292w5b3beb7a59446398@mail.gmail.com>
Date:	Sat, 27 Feb 2010 18:38:15 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
	davem@...emloft.net, perfmon2-devel@...ts.sf.net, eranian@...il.com
Subject: Re: [PATCH] perf_events: improve x86 event scheduling (v5)

2010/1/19 Peter Zijlstra <peterz@...radead.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/