Page MenuHomePhabricator

[esan] Add sideline itimer support

Authored by bruening on May 27 2016, 2:18 PM.



Adds support for creating a separate thread for performing "sideline"
actions on a periodic basis via an itimer. A new class SidelineThread
implements this feature, exposing a sampling callback to the caller.

Adds initial usage of sideline sampling to the working set tool. For now
it simply prints the usage at each snapshot at verbosity level 1. Adds a
test of this behavior. Adds a new option -record_snapshots to control
whether we sample and a new option -sample_freq to control the periodicity
of the sampling.

Diff Detail


Event Timeline

bruening updated this revision to Diff 58838.May 27 2016, 2:18 PM
bruening retitled this revision from to [esan] Add sideline itimer support.
bruening updated this object.
bruening added a reviewer: aizatsky.
bruening added subscribers: llvm-commits, eugenis, kcc and 2 others.

Friendly ping

vitalybuka accepted this revision.Jun 2 2016, 1:47 PM
vitalybuka added a reviewer: vitalybuka.

LGTM with nits

44 ↗(On Diff #58838)

and remove if() and unreachable below

61 ↗(On Diff #58838)

CHECK_EQ here and below

73 ↗(On Diff #58838)

SigAltStack = {} and no need memset

88 ↗(On Diff #58838)

just CHECK(Thread->adjustTimer(Thread->Freq)) ?

This revision is now accepted and ready to land.Jun 2 2016, 1:47 PM
aizatsky added inline comments.Jun 2 2016, 2:00 PM
49 ↗(On Diff #58838)

I think you should add overrun detection in case your function is slow from day 1.
You would get very unreliable results if you hit this, and it would be hard to tell why,

bruening marked 2 inline comments as done.Jun 3 2016, 9:16 AM
bruening added inline comments.
49 ↗(On Diff #58838)

I would like to do that in a separate CL as it is not simple -- as we're using a real-time timer, a heavily loaded machine could result in an occasional sample still being processed when the next alarm arrives, which won't be a big deal. We'd want to collect a count and report at the end the number of overlaps. I.e., it wouldn't just be unblocking the signal, setting a flag inside, and a CHECK that the flag is not set on entry.

73 ↗(On Diff #58838)

The worry is that the compiler will call libc memset and hit the interceptor. There are only 3 fields so that's unlikely here, but just setting ss_flags to 0 should be enough.

88 ↗(On Diff #58838)

Best not to place key actions inside a CHECK but I can do a CHECK on the result stored in a var.

This revision was automatically updated to reflect the committed changes.