-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
is-instance check to determine the type of a plugin for teardown decision #8741
Conversation
for more information, see https://pre-commit.ci
Codecov Report
@@ Coverage Diff @@
## master #8741 +/- ##
======================================
- Coverage 93% 93% -0%
======================================
Files 169 169
Lines 14071 14070 -1
======================================
- Hits 13040 13039 -1
Misses 1031 1031 |
@@ -947,7 +946,7 @@ def _run(self, model: "pl.LightningModule") -> Optional[Union[_EVALUATE_OUTPUT, | |||
|
|||
# teardown if necessary (similar calls for spawn plugins are excluded as they have | |||
# been included at the end of `new_process` functions) | |||
if self._distrib_type not in DistributedType.interactive_compatible_types(): | |||
if not isinstance(self.training_type_plugin, DDPSpawnPlugin): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- should we add a test to confirm DDP spawn and other parallel plugins all work as expected to avoid potential regressions here in the future?
- for custom plugins, this doesn't generalize unless they all extend DDP Spawn. should the plugin denote that it uses multiprocessing spawn method to create new processes, and that we need this in order to determine the appropriate teardown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes it does not generalize to plugins that do spawn but are not subclassing our ddp spawn plugin, but this was a tradeoff introduced in #8685. However, the change in this PR covers the case of plugins that don't spawn and therefore get a teardown at the right place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely, agreed that we should fix this first. I meant the custom plug-in support as a follow up beyond the scope of this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM !
What does this PR do?
Addresses a comment on recently merged PR #8685 (comment) which got missed/misinterpreted regarding the check for a type of plugin.
The plugin types classified as "interactive_compatible_types" do not relate directly to the plugin types that require a special place for teardown. These are the plugins that use the multiprocessing "spawn" method to create new processes but the DP plugin is NOT of this type and with the recent changes now does not have a teardown anymore.
Also, with #8685 custom accelerators would not receive a teardown.
This PR fixes that.
NOTE: labelling this as 1.5 bugfix as #8685 was also labelled this way.
Before submitting
PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:
Did you have fun?
I made sure I had fun coding 🙃