Short answer
The current in–kernel hibernation code (swsusp / suspend-to-disk) does not contain, and has never contained, a facility that “remembers which pages were in RAM and puts them back there before userspace is thawed”. If a page had been pushed out to swap before you hibernate, it will still be in swap after you resume and it will be faulted back on demand, one page-fault at a time. There is no kernel configuration switch, boot parameter or run-time knob that changes this behaviour.

Why it is done this way

1. What is saved
   • At hibernate time every task is frozen, the kernel walks the list of present (i.e. RAM-resident) pages, compresses them and writes them to the image.
   • Pages that were already swapped out are not read back in only to be written out again to the image – that would double the I/O and greatly enlarge the image.

2. Practical constraints
   • Reading every swapped-out page would require a lot more memory (you have to keep the snapshot itself in RAM while you are building it).
   • The code that builds the image runs with all non-essential drivers suspended; doing extra I/O there would be slow and fragile.

3. After resume
   • The kernel restores its image, re-enables interrupts and devices, then thaws tasks.
   • From that point on everything looks exactly as it did before hibernation, including the swap map, so pages are pulled in lazily as the processes touch them – and you feel the sluggishness you describe.

Can I get the behaviour I want in some other way?

1. Make sure nothing is swapped out before you hibernate
   This works because anything that is in RAM will be included in the snapshot and therefore will be back in RAM the instant the image is restored.

   How to do it: • Lower swappiness permanently (sysctl vm.swappiness=1) so the kernel avoids swapping in normal operation.
   • Or, explicitly disable swap just before hibernating:
   swapoff -a # wait until the pages are brought back
   systemctl hibernate
   You do the swapoff while the machine is still fully operational, so the re-paging happens while you can spare the time; after the next boot you can re-enable swap with swapon -a.

   Notes:
   • The swap device that the hibernation image itself is written to must stay enabled; if you use a swap partition for hibernation keep that one and disable the others, or use a dedicated swap-to-file for hibernation.
   • Of course this requires that the machine really has enough RAM to keep everything resident.

2. Use compressed RAM-based swap (zram/zswap)
   If the only swapped-out pages live in compressed RAM, they are already present after resume and faults are cheap. You still need enough RAM for this to be viable.

3. Use an out-of-tree patch set
   The last project that tried to implement aggressive pre-fetching of swapped pages was TuxOnIce (formerly suspend2) combined with Con Kolivas’ “swap-prefetch” patch. Those patches have not been maintained for current kernels, and you would have to build and maintain your own kernel to use them.

Why the kernel developers have not added “prefetch on resume”
• It increases hibernate and resume times and image size for everyone, even for people who are not swapping.
• It is not always possible (image might not fit if you have to pull everything in).
• The majority of desktops/laptops today have enough RAM that they rarely swap heavily, so the gain is considered too small to justify the complexity.

Bottom line
With stock Linux you can only avoid the sluggishness by ensuring there is nothing in swap when you freeze the system. Do that (lower swappiness or swapoff before hibernate) and the machine will be fully responsive immediately after every resume.