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
+23-6Lines changed: 23 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,8 +85,8 @@ This service is multi-thread safe. Note that when run multi-threaded the maximum
85
85
This service registers a monitor when the service is created (after python parsing is finished but before any modules
86
86
have been loaded into cmsRun) and prints its accumulated information to the specified file at specified intervals. Both
87
87
the file name and interval are specified by setting parameters of the service in the configuration. The parameters are
88
-
- filename: name of file to which to write reports
89
-
- millisecondsPerMeasurement: number of milliseconds to wait between making each report
88
+
-`filename`: name of file to which to write reports
89
+
-`millisecondsPerMeasurement`: number of milliseconds to wait between making each report
90
90
91
91
The output file contains the following information on each line
92
92
- The time, in milliseconds, since the service was created
@@ -108,10 +108,27 @@ This service registers a monitor when the service is created (after python parsi
108
108
have been loaded into cmsRun) and writes module related information to the specified file. The file name, an optional
109
109
list of module names, and an optional number of initial events to skip are specified by setting parameters of the
110
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.
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
114
115
115
The beginning of the file contains a description of the structure and contents of the file.
116
116
117
-
This service is multi-thread safe.
117
+
This service is multi-thread safe.
118
+
119
+
120
+
### ModuleEventAllocMonitor
121
+
This service registers a monitor when the service is created (after python parsing is finished but before any modules
122
+
have been loaded into cmsRun) and writes event based module related information to the specified file. The service
123
+
keeps track of the address of each allocation requested during an event from each module and pairs them with any
124
+
deallocation using the same address. The list of addresses are kept until the event data products are deleted at which
125
+
time the dallocations are paired with allocations done in a module. The list of addresses are then cleared (to keep memory usage down) but the amount of unassociated deallocations for each module is recorded per event.
126
+
The file name, an optional list of module names, and an optional number of initial events to skip are specified by setting parameters of the
127
+
service in the configuration. The parameters are
128
+
-`filename`: name of file to which to write reports
129
+
-`moduleNames`: list of modules which should have their information added to the file. An empty list specifies all modules should be included.
130
+
-`nEventsToSkip`: the number of initial events that must be processed before reporting happens.
131
+
132
+
The beginning of the file contains a description of the structure and contents of the file. The file can be analyzed with the helper script `edmModuleEventAllocMonitorAnalyze.py`. The script can be used to find modules where the memory is being retained between Events as well as modules where the memory appears to be growing Event to Event. Use `--help` with the script for a full description.
0 commit comments