ci: use zram instead of on-disk swap #27733

thunder-coding · 2025-12-22T10:54:15Z

No description provided.

thunder-coding · 2025-12-22T11:01:31Z

Seems like the zram module isn't available for azure VMs (which is internally used by GitHub action runners). Guess we will have to keep on using slower swapfiles then

TomJo2000 · 2025-12-22T11:25:43Z

We could test if Zswap is available, maybe that'll let us use a smaller swapfile.
https://wiki.archlinux.org/title/Zswap

licy183 · 2025-12-22T15:48:51Z

IIRC kernel modules on GitHub CI need to be compiled from source to run. I used to compile anbox-modules from source on GitHub CI in TUR [1]. If necessary, we can try compiling zram module from source to see if it works or not.

[1] termux-user-repository/tur@c4d183b

TomJo2000 · 2025-12-22T16:09:19Z

What's the CI time overhead on that?

Can we compile the Kernel modules ahead of time or does that need to happen on the CI every run?
Also how are the Kernel modules loaded at runtime?
Does DKMS work for that?

licy183 · 2025-12-22T16:17:18Z

What's the CI time overhead on that? Can we compile the Kernel modules ahead of time or does that need to happen on the CI every run?

I think that it can be done using Github Cache.

Also how are the Kernel modules loaded at runtime? Does DKMS work for that?

IIRC anbox-modules were loaded using dkms. The main issue is that GitHub Actions uses its own kernel, whose kernel module directory is different from the one in Ubuntu, so modules installed using apt cannot be loaded directly.

thunder-coding · 2025-12-22T16:49:18Z

Let me see if I can get this thing going with zram dkms module

thunder-coding · 2025-12-22T22:16:39Z

There we go. Some cleaning required. Then we can go ahead and get the builds for zram cached using GitHub Cache, and it should be pretty quick to load instead of 1m on cloning the kernel. Will probably get this in a day or two

robertkirkman · 2025-12-22T23:13:39Z

.github/workflows/packages.yml

    - name: Set process id limit for 32-bit builds depending on aosp-libs
      run: echo 65535 | sudo tee /proc/sys/kernel/pid_max
+    - name: Setup zram for packages that need more memory
+      run: |


I assume this will be adjusted so that it is still only run conditionally when the packages requiring free-space.sh are being built, right?

It should be possible to after splitting this step into 3 steps:

extraction of kernel version on the runner VM

Using the kernel version as key for storing into github actions cache

optionally building the module on cache miss

All these steps can be set to only run if large packages are being built

Although I would prefer to keep this to always on. zram should not negatively affect performance if it is not being used. Also it should improve performance when a process which is just hogging memory without using it is moved over to zram. We can test this on CI, and see if it is worth keeping this on by default

.github/workflows/packages.yml

TomJo2000 · 2025-12-23T10:48:03Z

On a procedural note since I'm seeing it in the commit log here.
You might be interested to know about the git commit --squash=<commit-ish>¹ option.

That lets you mark commits in a way that they're automatically sorted to be squashed into the commit they are linked to during a git rebase -i. Provided you pass the --autoquash to git merge or set:

[rebase]
	autosquash = true

in your git config (either ~/.gitconfig or ~/.config/git/config).

This also automatically makes git rebase ignore the commit messages of the designated squash commits during the reword part of the squash.

git commit --squash= should also offer tab completions from your shell so you don't need to remember the commit hashes yourself.

https://man.archlinux.org/man/git-commit.1#OPTIONS:~:text=1)%20for%20details.-,%2D%2Dsquash%3D%3Ccommit%3E,-Construct%20a%20commit ↩

thunder-coding · 2025-12-23T10:52:42Z

I needed the commit messages of in-between changes for rewriting the commit history once done. This PR is ready for review once I do that.

Also thanks for the git commit --squash, didn't knew of that. TIL!

TomJo2000 · 2025-12-23T10:55:48Z

I needed the commit messages of in-between changes for rewriting the commit history once done. This PR is ready for review once I do that.

Yep no worries.

Also thanks for the git commit --squash, didn't knew of that. TIL!

Found out about that one somewhat recently and it's been a really useful addition to my workflow.
Makes it way easier to do fixups to multi-commit branches.
It's kind of like a generalization of git commit --amend.
And I don't think I've managed to cause any conflicts during rebase from --squash commits alone so far, so that's a big plus as well.

thunder-coding · 2025-12-23T11:13:17Z

Thanks! git commit --squash worked pretty well (except for the mess-ups I created myself). Was able to reorder some commits as well pretty well. Not sure why stacked PRs are so much in trend in the industry nowadays than just relying on this feature which is built into git itself

.github/workflows/packages.yml

TomJo2000 · 2025-12-23T11:18:52Z

.github/workflows/packages.yml

+    - name: Extract VM kernel version for module compilation
+      id: kernel-info
+      run: |
+        KERNEL_VERSION="$(uname -r | grep -o "^[0-9\\.]*")"
+        TAR_KERNEL_VERSION="${KERNEL_VERSION%\.0}"
+
+        echo "kernel_version=${KERNEL_VERSION}" >> "$GITHUB_OUTPUT"
+        echo "tar_version=${TAR_KERNEL_VERSION}" >> "$GITHUB_OUTPUT"
+        echo "modules_dir=/lib/modules/$(uname -r)" >> "$GITHUB_OUTPUT"
+
+    - name: Restore cached zram kernel module
+      id: cache-zram
+      uses: actions/cache/restore@v5
+      with:
+        path: scripts/zram.ko.zst
+        key: ${{ steps.kernel-info.outputs.kernel_version }}-${{ hashFiles('scripts/linux-kernel-signing-keys.gpg') }}-${{ hashFiles('.github/workflows/packages.yml') }}
+
+    - name: Build zram kernel module
+      if: steps.cache-zram.outputs.cache-hit != 'true'


How exactly does the GHA caching work anyway?
Build zram kernel module is conditioned on getting a cache miss.

But I'm guessing we need the kernel version to check the cache in the first place?

The paths specified by path are cached by GHA. If some data is available with the specified key, then it is restored (happens above in actions/cache/restore step). The key is set to the kernel version as well as the script which is running and the files which we are using (the signing keys for the kernel)

We only need to build the module if we couldn't restore from cache.

We further save the cache just after we build the module and load it.

thunder-coding · 2025-12-23T13:53:32Z

This PR should be ready for review. Some action runs:

https://github.com/termux/termux-packages/actions/runs/20459568208?pr=27733

Older runs before cleaning commits showing that caching of the built DKMS module works:

https://github.com/termux/termux-packages/actions/runs/20458562801/job/58786018803?pr=27733 (DKMS module was built here)
https://github.com/termux/termux-packages/actions/runs/20459325908/job/58788341889?pr=27733 (Prebuilt module used from cache)

.gitignore

Should improve performance when compiling large packages. And zram should be unused unless there is requirement for it's usage. Not sure how much will it affect packages that do not need additional memory (needs to be monitored for CI usage after getting merged)

Changes made: - download tarball from cdn.kernel.org instead of git clone Also check the signature of the tarball - Manual install module instead of using modules_install modules_install does do the same thing and run depmod. We are running depmod ourselves. Also kernel Makefile will skip running depmod since System.map is not available on the VM - Also do zstd compression on the module. The kernel makefiles don't seem to do it by default

- Store some of the common variables as outputs for reuse - Manually restore and save cached zram.ko.zst. This should ensure that the builds are cached even when building packages fails - Additionally the built zram.ko.zst needs to be stored in scripts/ as GHA doesn't support caching absolute paths well: See issues: - actions/cache#1127 - actions/cache#1540 which was worked around in oro-os/toolchain@ebcad88 by using relative path Also restoring cache in /lib/modules/ would require actions/cache/restore to run as root, and exists no documented way to do that which I could find online

thunder-coding closed this Dec 22, 2025

thunder-coding reopened this Dec 22, 2025

thunder-coding self-assigned this Dec 22, 2025

thunder-coding added this to @thunder-coding's public tracker Dec 22, 2025

robertkirkman reviewed Dec 22, 2025

View reviewed changes

thunder-coding force-pushed the zswap branch 3 times, most recently from 81957a4 to 3f9033f Compare December 23, 2025 11:11

thunder-coding moved this to In Progress in @thunder-coding's public tracker Dec 23, 2025

TomJo2000 reviewed Dec 23, 2025

View reviewed changes

thunder-coding marked this pull request as ready for review December 23, 2025 11:44

thunder-coding requested a review from Grimler91 as a code owner December 23, 2025 11:44

thunder-coding force-pushed the zswap branch from 02a3f36 to b2ea4ea Compare December 23, 2025 13:50

robertkirkman reviewed Dec 23, 2025

View reviewed changes

.gitignore Outdated Show resolved Hide resolved

thunder-coding added 4 commits December 24, 2025 13:05

ci(packages): strict mode for all zram scripts

93e2b74

thunder-coding force-pushed the zswap branch from b2ea4ea to 93e2b74 Compare December 24, 2025 07:36

thunder-coding changed the title ~~ci: us zram instead of on-disk swap~~ ci: use zram instead of on-disk swap Dec 24, 2025

Uh oh!

ci: use zram instead of on-disk swap #27733

Are you sure you want to change the base?

ci: use zram instead of on-disk swap #27733

Conversation

thunder-coding commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thunder-coding commented Dec 22, 2025

Uh oh!

TomJo2000 commented Dec 22, 2025

Uh oh!

licy183 commented Dec 22, 2025

Uh oh!

TomJo2000 commented Dec 22, 2025

Uh oh!

licy183 commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thunder-coding commented Dec 22, 2025

Uh oh!

thunder-coding commented Dec 22, 2025

Uh oh!

robertkirkman Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thunder-coding Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

TomJo2000 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

thunder-coding commented Dec 23, 2025

Uh oh!

TomJo2000 commented Dec 23, 2025

Uh oh!

thunder-coding commented Dec 23, 2025

Uh oh!

Uh oh!

TomJo2000 Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

thunder-coding Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thunder-coding commented Dec 23, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

thunder-coding commented Dec 22, 2025 •

edited

Loading

licy183 commented Dec 22, 2025 •

edited

Loading

robertkirkman Dec 22, 2025 •

edited

Loading

TomJo2000 commented Dec 23, 2025 •

edited

Loading

thunder-coding Dec 23, 2025 •

edited

Loading