Hey Lennart.
On Wed, 2023-03-29 at 16:35 +0200, Lennart Poettering wrote: > In almost all scenarios you want swap, regardless if little RAM or a > lot. For specialist cases where you run everything from memory, and > not even programs are backed by disk there might be exceptions. Similar to the latter example of yours, one could think of scenarios with little disk space, where it might be interesting to use a swap file for hibernation, but have the storage available when the system is up. > But > that#s almost never the case. IMO that's always hard to say... in WLCG we actually have compute nodes with little to no disk space but plenty of RAM (or well at least a certain amount of GB per core). Though we don't need hibernation there. > It allows the kernel to reclaim anonymous memory, because it can > write > it to disk and then use it for other purposes. Well that's clear, it's just that on my systems (both servers and workstations) I've never really run into the need to reclaim lots of anonymous memory. It was apparently always enough to have cached data reclaimed. > swap is not an "extra > on top", that's a complete misunderstanding how modern memory > management works. By avoiding swap you create artificial > (i.e. unnecessary) scarcity, and disallow the kernel to use RAM for > useful purposes because you block it with anonymous memory that might > never be used. You artificially amplify IO on the file-backed pages > hence, because those become the only ones that are reclaimable. Well, I have been operating like that for many years now, and back then I actually run into trashing more often, so maybe my experiences are just outdated :D If things changed, I'll happily try again to run with swap and see how it turns out for my use cases :-) > https://chrisdown.name/2018/01/02/in-defence-of-swap.html Thanks for the pointer. On Wed, 2023-03-29 at 16:36 +0200, Lennart Poettering wrote: > Yeah, all requests that go through logind check that. > > You can override the check via an environment variable, > SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1 btw, see > https://systemd.io/ENVIRONMENT/ Nice, that did the trick. Perfect that it's an env var that takes effect at logind, so one can easily add it to the env of just that via the unit file, without the need to fiddle around with bashrc and friends. Since you're anyway rather against the whole idea,... I assume you wouldn't want a PR that adds something like that as an example to the manpages? Or perhaps somehow a hint that logind is consulted first and thus the swap area needs to be already there or the check disabled? Another thing that could be worth to add somewhere is where people are intended to add other service dependencies for things that should be done before/after suspend/resume/etc. ... i.e. the respective .target and not .service. Might make it easier for people to use it properly :-) In any case, thanks for your help :-) Cheers, Chris.