generic: disable kernel SWAP support

[blocktrron]

We don't employ swap using zram anymore with Gluon. Thus, we can disable SWAP in the kernel.

[Djfe]

Wouldn't it make more sense to employ it for certain devices instead?

[blocktrron]

@Djfe WHere should we swap to?

[Djfe]

why, RAM of course. zRAM to be exact
it's a very useful thing and even Google recommends using it for Android
https://developer.android.com/topic/performance/memory-management

and it prevented tiny devices in the past (32mbit RAM) from OOMing early.

imo it probably makes sense for many targets.
especially targets with just 64MiB of RAM and targets which employ smallbuffers.
Considering kernels are growing in size from time to time zRAM should help mitigate that for a while.

Obviously this should be tested but I don't think that this would reduce/harm performance in any way.
Also it will reduce ram footprint for the status page when it's not in use.

I'm happy to provide before and after for targets. if you are on board with such a change.

I would not set zRAM to 50% like it was done here for a nanostation xw. 29mb might be a bit much on 64MiB devices/more than necessary.
yes, zRAM is a permanent balloon but if configured correctly should allow for more total/virtual RAM when faced with more clients. Obviously we should watch whether we increase certain deadlocks under load

maybe relevant
#1692 (comment)

if we keep zRAM small it could be of use to evaluate zst compared to LZ4
https://dev.to/archerallstars/lets-fine-tune-your-zram-aka-free-ram-in-opensuse-with-zstandard-aka-zstd-4eap

cpu usage should be negligible if this stores mostly paged which are barely used. if zRAM takes up too much RAM, then this won't be the case because Linux has to swap constantly.

thoughts?

[blocktrron]

imo it probably makes sense for many targets.

You burn CPU time doing so. You can only swap out userspace pages which are not the big concern for us.

Considering kernels are growing in size from time to time zRAM should help mitigate that for a while.

We have no issue in the present tense, so why try to add complexity on a non-issue today?

Obviously this should be tested but I don't think that this would reduce/harm performance in any way.
Also it will reduce ram footprint for the status page when it's not in use.

See the last point, what do you expect to gain except for a higher "Memory Available" counter?

should allow for more total/virtual RAM when faced with more clients

The buffers for wireless clients exist in kernelspace, there is just a miniscule space required within hostapd.

Last time we've used it as a last dirch effort and it did not make the boards in question usable again. We do not face any issue today, so why should we hop onto the bandwagon we used in the past for a short time when there is no need to today?

[Djfe]

the userspace part is something I actually didn't know about. Thanks for elaborating why it's not that easy and why OpenWrt doesn't profit from this as much.

See the last point, what do you expect to gain except for a higher "Memory Available" counter?

mostly: Support for more concurrent WiFi clients by more RAM being available for that purpose.
For me this was more of a feature idea than a workaround. I expected this to improve devices overall.