On Wed, May 07, 2025 at 12:18:53AM -0700, patrick keshishian wrote:
> This is potentially a very dumb question; please bear with me.
>
> I have an older thinkpad currently running OpenBSD 7.6. I have
> recently added more RAM to the thinkpad, so the swap partition is
> smaller than available RAM.
>
> Is there a way I can prevent OBSD from entering hibernation state?
>
> Reading apmd(8), I didn't see anything obvious, but I got the false
> hope that if any of the /etc/apm/{hibernate,standby,suspend} were to
> exit with non-0 exit code, maybe the respective state transition would
> be aborted. I tried zzz(8) with /etc/apm/suspend with only false(1),
> but that did not prevent zzz(8) suspending.
>
> --patrick
>
> [longer background - can ignore]
> In the dark, I must have fat-fingered and hit the Fn+suspend-to-disk
> combination. I have never before attempted hibernation so I had no
> idea what the process entails. The system seemed to go through
> similar steps as it does during suspend, but after blanking the screen
> the power button light continued flashing, and seemed to just continue
> forever. I assume(d) b/c the swap size is too small for current
> memory, the process was stuck in a loop. I eventually powered-off and
> restarted, and never having experienced hibernation cycle, I learned
> OBSD tried to unpack (I assume) an incomplete image, which after an
> interesting graphics display dropped me into ddb :-)
>
> I am hoping there is a simple way to prevent hibernation from even
> being attempted, at least, until I resize my swap partition.
>
> I assume the hibernate path is much too complicated and a simple if
> (swap_size < mem) check to abort hibernation is infeasible.
>
We don't have that check. It wouldn't be that hard to add. I intentionally
didn't do this before because:
1. we compress the image, and skip any unused pages. I've never seen a situation
where we even came close to needing the full amount of swap equal to ram.
2. when we allocate swap, we need a contiguous extent anyway, so even saying
"you must have as much swap as physical ram" really doesn't guarantee it
will succeed either. If swap is heavily fragmented, you're out of luck,
even if you have enough available in total.
Could the heuristic be better? Sure. But TBH nobody really has complained
too much about it and it's been like this for over a decade.
If you want to add the check, I'd put it in uvm_hibswap. If you improve it
substantially, to include extent checking for the max RAM size to avoid
fragmentation, your diff would be welcome on tech@. Please share if that's
the case. I'd be happy to review it.
-ml
