Adopt Brent's algorithm for cycle detection #746
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
geky
added
enhancement
needs minor version
geky
force-pushed
the
brent-cycle-detection
branch
from
6a041ed to
fd9cc9a
Compare
geky
force-pushed
the
test-and-bench-runners
branch
from
78ebd80 to
d677a96
Compare
geky
force-pushed
the
brent-cycle-detection
branch
from
fd9cc9a to
c4c72fd
Compare
geky
force-pushed
the
test-and-bench-runners
branch
from
d677a96 to
2d2dd8b
Compare
geky
force-pushed
the
brent-cycle-detection
branch
2 times, most recently
from
4f2c237 to
55530d4
Compare
geky
force-pushed
the
test-and-bench-runners
branch
from
076f871 to
17c9665
Compare
geky
force-pushed
the
brent-cycle-detection
branch
from
55530d4 to
e4d1c7f
Compare
geky
force-pushed
the
test-and-bench-runners
branch
from
17c9665 to
1f37eb5
Compare
geky
force-pushed
the
brent-cycle-detection
branch
from
e4d1c7f to
cb6c56f
Compare
The previous cycle detection algorithm (a naive check against the largest possible tail list) is simple and gets the job done, but has the potential to take a very long time on disks with many blocks. Brent's algorithm, on the other hand, takes at most 2x the number of blocks in the tail list. Originally naive cycle detection was chosen over Floyd's algorithm to avoid the extra complexity of managing two desynced traversals for every traversal of the tail list, but Brent's algorithm is very well suited for our use case, requiring only we keep track of an additional mdir pointer on the stack as we traverse.
geky
force-pushed
the
brent-cycle-detection
branch
from
cb6c56f to
1278ec1
Compare
geky
removed
the
needs minor version
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous cycle detection algorithm (a naive check against the largest possible tail list) is simple and gets the job done, but has the potential to take a very long time on disks with many blocks. Brent's algorithm, on the other hand, takes at most 2x the number of blocks in the tail list.
The naive cycle detection algorithm was originally chosen as I was only aware of Floyd's algorithm at the time (the classic tortoise+hare cycle detection). Floyd's algorithm is a poor fit for littlefs as it requires managing two desynced traversals of the tail list, which comes with quite a bit of complexity+code cost. But Brent's algorithm is very well suited for littlefs, requiring only an additional mdir pointer in RAM.
The benefit of adopting Brent's algorithm is not just to speed up cycle detection, but to make cycle detection distinguishable from an infinite loop.
Also added a warning message to help debug when there is an infinite loop. Though this should never happen unless 1. there's a bug in littlefs, or 2. the image on disk is malicious.