FastTimerService: add measurement of framework overhead (100x) #21446
Conversation
fwyzard
commented
Nov 23, 2017
fwyzard
commented
- measure the time spent in the event loop, but outside any module
- keep track of the threads joining and leaving the TBB global arena
This measurement is meaningful only only for single-threaded, single-stream jobs, where it can be used as a comparison with the measurement based on the sum of the resources spent in each module.
|
The code-checks are being triggered in jenkins. |
|
@cmsbuild, please test |
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/PR-21446/2169 Code check has found code style and quality issues which could be resolved by applying a patch in https://cmssdt.cern.ch/SDT/code-checks/PR-21446/2169/git-diff.patch You can run |
Enabled checks:
boost-use-to-string
cppcoreguidelines-no-malloc
google-build-explicit-make-pair
misc-inefficient-algorithm
misc-string-compare
misc-uniqueptr-reset-release
modernize-avoid-bind
modernize-deprecated-headers
modernize-loop-convert
modernize-make-shared
modernize-make-unique
modernize-pass-by-value
modernize-redundant-void-arg
modernize-replace-auto-ptr
modernize-shrink-to-fit
modernize-use-auto
modernize-use-bool-literals
modernize-use-emplace
modernize-use-equals-default
modernize-use-equals-delete
modernize-use-nullptr
modernize-use-override
modernize-use-transparent-functors
modernize-use-using
performance-faster-string-find
performance-for-range-copy
performance-implicit-cast-in-loop
performance-inefficient-string-concatenation
performance-type-promotion-in-math-fn
performance-unnecessary-copy-initialization
performance-unnecessary-value-param
readability-container-size-empty
readability-redundant-string-cstr
readability-static-definition-in-anonymous-namespace
readability-uniqueptr-delete-release
See http://releases.llvm.org/4.0.0/tools/clang/tools/extra/docs/clang-tidy/index.html for details.
fwyzard
force-pushed
the
FastTimerService_add_overhead_measurement_100x
branch
from
74e7be5
to
4cfbe07
Compare
|
The code-checks are being triggered in jenkins. |
|
@cmsbuild, please test |
|
+code-checks |
|
The tests are being triggered in jenkins. |
|
A new Pull Request was created by @fwyzard (Andrea Bocci) for master. It involves the following packages: HLTrigger/Timer @Martin-Grunewald, @silviodonato, @cmsbuild, @fwyzard can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 |
cmsbuild
added
fully-signed
hlt-approved
and removed
hlt-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
| // inherited from TBB task_scheduler_observer | ||
| void on_scheduler_entry(bool worker) final; | ||
| void on_scheduler_exit(bool worker) final; | ||
|
|
There was a problem hiding this comment.
@Dr15Jones do you think it might be useful to monitor these also in other services, like the Tracer ?
There was a problem hiding this comment.
We already monitor it in the code that does the crash logging (in order to capture which modules are in which threads). I had not contemplated where else it might be useful.
There was a problem hiding this comment.
OK. I've added it to the FastTimerService to track the resources used in a new thread before it starts working on some module.
There was a problem hiding this comment.
Be forewarned, the framework turns TBB on right up front during the initialization phase which is well before the framework explicitly starts to create TBB tasks. Therefore you should see lots of 'dead' startup time.
There was a problem hiding this comment.
[NOTE: it is possible that TBB does 'lazy' thread creation and therefore waits until the first TBB task is requested before it starts creating the threads. I think that better explains what I see in the debugger so you might not have much 'dead' startup time.]
