Is there a specific reason why CONFIG_SWAP is disabled in GL-BE3600 kernel?
root@be3600:~# zcat /proc/config.gz | grep CONFIG_SWAP
# CONFIG_SWAP is not set
This means swap support is completely absent at kernel level. As result, zram cannot function.
On a low-RAM device, this severely impacts memory reclaim behavior under I/O pressure.
Is this an intentional design decision, or an oversight in kernel configuration?
If intentional, what is the rationale for it?
Please consider enabling CONFIG_SWAP (and related options CONFIG_ZRAMCONFIG_ZSMALLOC) in a future firmware update, as zram is essential for system stability on memory-constrained devices.
This behavior is expected on GL.iNet Qualcomm-based devices and is not a standalone issue of the GL-BE3600.
Devices like GL-BE3600, GL-BE9300 (Flint 3) and GL-BE9600 share the same architectural philosophy:
Qualcomm QSDK
NSS hardware offloading as a first-class feature
A deliberately reduced kernel configuration
In this context, CONFIG_SWAP being disabled is not a missing feature, it is a design decision.
The firmware is optimized for deterministic performance and hardware acceleration, not for generic OpenWrt extensibility.
I ran into a very similar situation on the GL-BE9300, where several “bugs” turned out to be expectation mismatches caused by assuming generic OpenWrt behavior on a Qualcomm + GL.iNet stack.
Once you stop treating the device like vanilla OpenWrt and align with the intended architecture, the problems disappear.
I documented that investigation and resolution here, in case it helps to understand the broader pattern:
The short version:
Swap is intentionally disabled
Heavy reliance on NSS means avoiding features that interfere with deterministic memory and fast-path traffic
Similar limitations appear across multiple GL.iNet Qualcomm models for the same reason
So this is not a regression or a misconfiguration on the BE3600.
It’s consistent behavior across the product line
While it’s clear to me now that this is a conscious design choice, it's one that is pretty hard to justify just with NSS hardware offloading being a first-class feature. Zram is entirely RAM-backed, does not introduce I/O latency, and does not interfere with NSS fast-path operation. Simply enabling kernel support for it doesn’t force anyone to use it and doesn’t negatively affect users who choose not to.
Additionally, hardware acceleration itself is a toggle, not something that is permanently locked on, which makes the argument for disabling zram even weaker.
I don’t treat GL.iNet devices like vanilla OpenWrt. However, both LuCI and the OpenWrt package manager are still present in the firmware, so the ability to install and use available packages is an implied feature - one that is silently hindered by this kernel configuration.
From any angle, this is still a missing feature, deliberate or not.
So while I understand the reasoning behind this design choice, I strongly disagree with it and hope future releases give users more freedom in a way that better reflects the philosophy of the underlying OS. After all, GL.iNet promotes OpenWrt as the base for their firmware, so it would make sense to respect that philosophy more fully.
I came here to second this. I just spent an hour trying to figure out why I couldn’t use my persistently connected external storage as host for a swapfile. I resorted to AI to step me through what I was missing. After we hit the hour mark, it finally said “oh, there’s this forum post”.
Either way, as you mention, I’m unsure how permitting swap would be system breaking when Zram exists. I hope the devs change their mind on this, truly.
Hi will.qiu. Understand that CONFIG_SWAP is disabled, but does this also apply to fstab settings? For example, adding an external drive with a swap partition and configuring fstab with: