-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release ProcessDesc in main() to release some memory #42503
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-42503/36509
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages:
@cmsbuild, @smuzaffar, @Dr15Jones, @makortel can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
-1 Failed Tests: RelVals RelVals-INPUT AddOn RelVals
Expand to see more relval errors ...RelVals-INPUT
Expand to see more relval errors ...
AddOn Tests
Expand to see more addon errors ... |
Looks like this PR is one of those that require some cleanup to be done first. A quick
|
What exactly was the "git grep" command used to generate the list of modules? I am wondering if we could miss items that we are referencing in this ParameterSet we want to delete. The getParameterSet and getParameterSetVector functions return references to internal vectors or ParameterSets. Even if we find and remove all of them, is there anything to prevent people from adding new code that saves such references? These might be difficult to identify, possibly pointing to something stale but valid sometimes and then yielding unpredictable results. Maybe the memory savings are worth the risk. It does concern me a little. |
git grep -E "ParameterSet ?&" | fgrep -v \( | fgrep \; | fgrep -v \) | fgrep -v =
I'd bet it missed something. I'm hoping the next round of testing (after all the cases identified in #42503 (comment) have been converted) would show more cases to migrate (if there are any).
Out of the box there would be nothing. But the situation is similar with e.g.
I agree this is a valid concern. The change should definitively be announced (although I hope we have never made any promises of the lifetime of the process PSet). Maybe a static analyzer check would help as well (such that it is enforced in PR tests)? |
PRs to address all the files in #42503 (comment) (some of them did not need action) have now been merged. I'd wait for the next IB before launching tests again. |
@cmsbuild, please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-1d46d6/34503/summary.html Comparison SummarySummary:
|
At this point it is probably best to wait for 13_4_X to be opened to avoid potentially breaking workflows (even if hopefully unlikely) towards the end of the release cycle, and to not disturb the code integration for HI data taking. |
@cmsbuild, please test To refresh. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-1d46d6/34847/summary.html Comparison SummaryThere are some workflows for which there are errors in the baseline: Summary:
|
@cmsbuild, plese test Refresh again |
@cmsbuild, please test Refreshing without a typo |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-1d46d6/34936/summary.html Comparison SummarySummary:
|
+core |
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. @antoniovilela, @rappoccio, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Profiling the live memory of #40437 (comment) showed that the
edm::ProcessDesc
was taking about 40 MBhttps://mkortela.web.cern.ch/mkortela/cgi-bin/navigator/issue40437/reco_07.5_live/496
The
ProcessDesc
is not really needed inmain()
after theEventProcessor
is constructed, so this PR releases the ownership ofProcessDesc
inmain()
, so that the object will be destructed in theEventProcessor
constructor.This change implies that the modules may no longer hold the
edm::ParameterSet
, that is given to their constructor, by reference/pointer (while testing the change I came across with #42502, but there may be more).Resolves cms-sw/framework-team#616
PR validation:
Workflow 11834.21 reco step runs with #42502
The IgProf MEM_LIVE in 11834.21 reco step in 13_2_0_pre3
There is residual ~1.7 MB contribution from
PyBind11ProcessDesc
that look like memory leaks in python itself(?).