You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: PerfTools/AllocMonitor/README.md
+16Lines changed: 16 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,9 @@ The monitor is owned by the registry and should not be deleted by any other code
29
29
of the monitor, one can call `cms::perftools::AllocMonitorRegistry::deregisterMonitor` to have the monitor removed from
30
30
the callback list and be deleted (again, without the deallocation causing any callbacks).
31
31
32
+
NOTE: Experience has shown that using thread_local within a call to `allocCalled` or `deallocCalled` can lead to unexpected behavior. Therefore if per thread information must be gathered it is recommended to make a system that uses thread ids.
33
+
An example of such code can be found in the implementation of ModuleAllocMonitor.
34
+
32
35
## General usage
33
36
34
37
To use the facility, one needs to use LD_PRELOAD to load in the memory proxies before the application runs, e.g.
@@ -99,3 +102,16 @@ The output file contains the following information on each line
99
102
- Number of calls made to deallocation functions
100
103
101
104
This service is multi-thread safe. Note that when run multi-threaded the maximum reported value will vary from job to job.
105
+
106
+
### ModuleAllocMonitor
107
+
This service registers a monitor when the service is created (after python parsing is finished but before any modules
108
+
have been loaded into cmsRun) and writes module related information to the specified file. The file name, an optional
109
+
list of module names, and an optional number of initial events to skip are specified by setting parameters of the
110
+
service in the configuration. The parameters are
111
+
- filename: name of file to which to write reports
112
+
- moduleNames: list of modules which should have their information added to the file. An empty list specifies all modules should be included.
113
+
- nEventsToSkip: the number of initial events that must be processed before reporting happens.
114
+
115
+
The beginning of the file contains a description of the structure and contents of the file.
0 commit comments