Honestly, though, reducing max-jobs and cores together is very powerful. I actually completed a build of webkitgtk on a 4GB arm device with zram swap once. It took a long time, but it succeeded.
Unstable shouldn’t miss the cache much more than stable. It still only advances after hydra’s done its job. It’s just that packages which don’t hold up channel advancement are more likely to be broken for short periods on unstable.
Zswap is enabled by kernel parameters. Confusingly, the NixOS options for zram are named zramSwap.
What you probably want is zswap.
boot.kernelParams = [
"zswap.enabled=1"
"zswap.compressor=zstd" # compression algorithm (LZ4 is faster, zstd is almost fast enough, but compresses better)
"zswap.max_pool_percent=20" # maximum percentage of RAM that zswap is allowed to use
"zswap.shrinker_enabled=1" # whether to shrink the pool proactively on high memory pressure
];
It cooperates better with real swap. A problem I have found is that it decompresses pages before swapping.
For those observing, I have been using an LVM VDO with only compression enabled as a swap device (swap files on FS with compression are another hack but were presumed to have higher overhead). It works. It kind of does what we want, but with limitations and extra steps.
What we really want is a zswapfs that is purpose built for compressed swap and then to use dictionary assisted compression for text sections and buffers because this seems to make zstd compress both smaller and faster, really mitigating the tradeoffs of the CPU usage and latency while greatly improving the compression ratios for commonly swapped data. VDO stats show that most of this data is one-way, never used again after being allocated and written.
Yeah, I think your real issue is here. You should not be getting cache misses all too regularly. Maybe you’re just affected by the recent electron failure; I’d recommend avoiding electron-based software as much as possible, not only because of the build failures.
Beyond that, it’s quite possible you have some unwise overrides or are using master or nixpkgs-unstable instead of nixos-unstable. Share your config, or at least your channels/inputs, NixOS should rarely mean rebuilding the world. If it does you should probably abort the build and just wait til tomorrow. This isn’t gentoo.
And that kernel params work in that case, but I concur that the recommendation to write a simple systemd script is the right way for module users. We don’t normally need zswap early. I was just messing around.
Yes, but how depends on which method for input specification you use. Channels, npins and flakes can all do multi-nixpkgs inputs.
Technically this is unsupported, since the software isn’t integrated properly, and it significantly increases disk space usage. It also probably doesn’t help much, I don’t think unstable sees meaningfully more electron rebuilds than stable, and even if it did the cache should be populated most of the time, the current situation is a bit of a fluke. You can still do this, there just isn’t much of a point to it.
Either way, best to avoid electron where possible. You’re just using an outdated chrome to open a website.
If you still see frequent rebuilds, share your code, if you don’t know what you’re doing and are copying a bunch of stuff it’s pretty easy to override something such that nix will always rebuild it when an input changes (which in turn is quite common because all reverse dependency changes cause downstream rebuilds). There is a lot of poor advice out there.
It’s not just overlays, certain nix and nixpkgs settings can do that too, and some options apply overrides (overrides != overlays, even if they are often used together) without being explicit about it - though those would much more rarely have that kind of impact.
