-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
moss: Prime vfs cache on boot via systemd service #548
Open
ermo
wants to merge
1
commit into
main
Choose a base branch
from
moss-prime-vfs-cache-at-boot
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
January 13, 2025 15:37
87b2c75
to
77f974d
Compare
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
2 times, most recently
from
January 13, 2025 15:49
4897a90
to
e628d53
Compare
ermo
added a commit
to serpent-os/lichen
that referenced
this pull request
Jan 13, 2025
Note that, in addition to being slow for cold blits, ext4 only supports 65k hardlinks per file, and it has a limit of 4k for combined extended attribute data as well. Given we are looking at supporting SELinux, there is a very real chance that we are artificially (and knowingly) limiting ourselves by offering ext4 as a rootfs for Serpent OS. NB: serpent-os/recipes#548 is now up as a way to help mitigate the ext4 and f2fs cold blit slowness until we figure out a better solution. Signed-off-by: Rune Morling <[email protected]>
ermo
added a commit
to serpent-os/lichen
that referenced
this pull request
Jan 13, 2025
Note that, in addition to being slow for cold blits, ext4 only supports 65k hardlinks per file, and it has a limit of 4k for combined extended attribute data as well. Given we are looking at supporting SELinux, there is a very real chance that we are artificially (and knowingly) limiting ourselves by offering ext4 as a rootfs for Serpent OS. NB: serpent-os/recipes#548 is now up as a way to help mitigate the ext4 and f2fs cold blit slowness until we figure out a better solution. Signed-off-by: Rune Morling <[email protected]>
On an old 4790K w/a SATA-600 SSD with ext4 rootfs, I got the following numbers: Hot vfs cache install blit (setup+teardown + blit): 13s-ish Video below is dinky, but does the job. ext4-hot-and-cold-vfs-cache-blit-2025-01-13.webm |
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
January 16, 2025 19:40
e628d53
to
ae9fc7c
Compare
ikeycode
reviewed
Jan 17, 2025
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
January 21, 2025 13:56
ae9fc7c
to
ae51eb8
Compare
This should serve to make the first blit after boot run against a hot vfs cache, which should improve the performance of the first blit for Serpent OS systems installed to ext4 or f2fs roots in particular. Neither ext4 nor f2fs blits will be as fast as xfs blits (though, surprisingly enough, ext4 blits come very close w/ hot blits), so xfs currently remains the recommended root filesystem for Serpent OS. Additionally, include a oneshot .service for testing the time to prime w/ a cold vfs cache. Per the request of @ikeycode this service is gated behind a `ConditionKernelCommandLine=moss.debug` flag, ensuring that it will never be started by accident. Users who need this sort of functionality can add a drop-in `/etc/kernel/cmdline.d/moss.debug.cmdline` snippet to access it. This PR was also rebased onto the main branch, which now shows blit stats on actions creating a new fstx. Signed-off-by: Rune Morling <[email protected]>
ermo
force-pushed
the
moss-prime-vfs-cache-at-boot
branch
from
January 21, 2025 14:04
ae51eb8
to
ba51c88
Compare
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.
This should serve to make the first blit after boot run against a hot vfs cache, which should improve the performance of the first blit for Serpent OS systems installed to ext4 or f2fs roots in particular.
Neither ext4 nor f2fs blits will be as fast as xfs blits (though, surprisingly enough, ext4 blits come very close w/ hot blits), so xfs currently remains the recommended root filesystem for Serpent OS.
Additionally, include a oneshot .service for testing the time to prime w/ a cold vfs cache. Per the request of @ikeycode this service is gated behind a
ConditionKernelCommandLine=moss.debug
flag, ensuring that it will never be started by accident.Users who need this sort of functionality can add a drop-in
/etc/kernel/cmdline.d/moss.debug.cmdline
snippet to access it.This PR was also rebased onto the main branch, which now shows blit stats on actions creating a new fstx.
Status after cold boot on xfs: