]> CyberLeo.Net >> Repos - FreeBSD/stable/9.git/commit
MFC 283123:
authorjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 1 Jun 2015 18:08:56 +0000 (18:08 +0000)
committerjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Mon, 1 Jun 2015 18:08:56 +0000 (18:08 +0000)
commit9cc750e0492781cceb43b7885f288d3ed9da74bd
tree8b31bfed276120a493f5b436c1984f9fd97b88f0
parent1460b7850a96bc562a57f83826326e27d88789dc
MFC 283123:
Fix two bugs that could result in PMC sampling effectively stopping.
In both cases, the the effect of the bug was that a very small positive
number was written to the counter. This means that a large number of
events needed to occur before the next sampling interrupt would trigger.
Even with very frequently occurring events like clock cycles wrapping all
the way around could take a long time. Both bugs occurred when updating
the saved reload count for an outgoing thread on a context switch.

First, the counter-independent code compares the current reload count
against the count set when the thread switched in and generates a delta
to apply to the saved count. If this delta causes the reload counter
to go negative, it would add a full reload interval to wrap it around to
a positive value. The fix is to add the full reload interval if the
resulting counter is zero.

Second, occasionally the raw counter value read during a context switch
has actually wrapped, but an interrupt has not yet triggered. In this
case the existing logic would return a very large reload count (e.g.
2^48 - 2 if the counter had overflowed by a count of 2). This was seen
both for fixed-function and programmable counters on an E5-2643.
Workaround this case by returning a reload count of zero.

PR: 198149
Sponsored by: Norse Corp, Inc.

git-svn-id: svn://svn.freebsd.org/base/stable/9@283886 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/hwpmc/hwpmc_core.c
sys/dev/hwpmc/hwpmc_mod.c