Fwd: systemtap global var lead to high cpu
Frank Ch. Eigler
fche@redhat.com
Tue Aug 18 19:11:16 GMT 2020
Hi -
Improvements made for PR26296 should dramatically improve
your global variable locking issues with systemtap. Please
let us know if it's enough!
https://sourceware.org/git/?p=systemtap.git;a=commit;h=25012d82e181afe7de5cb8bcc2cefcef0b123e32
- FChE
------------------------------------------------------------------------
PR26296: lock pushdown optimization
Implements an algorithm to push lock/unlock operations downward in the
syntax tree, to just enclose the smallest possible region that deals
with global variables. This means two common patterns run with much
more concurrency than before:
global a
probe foo {
if (condition)
{ a++ }
else
{ something_else() }
}
will only lock globals -if- the condition is true, so something_else()
would run unlocked. Also:
global a
probe foo {
if (a)
{ long_twisty_operation(); }
}
will unlock globals right after the condition is evaluated, so
long_twisty runs unlocked. Previous behaviour is avilable with
--compatible=4.3. New test case lock-pushdown.stp asserts locking
conditions throughout various relevant constructs.
More information about the Systemtap
mailing list