Specify priorities for swapfiles

[MilesBHuff]

As far as I can tell, Swapspace does not currently set priorities for its swapfiles. This means that the kernel swaps evenly across all of Swapspace's swapfiles; this has a significant downside in that, when deallocation happens, much more swap is released into RAM than is necessary. If instead each successive swapfile had a priority one lower than the file before it, the kernel would fill up older swapfiles before using newer ones; this significantly reduces the impacts of deallocating the largest swapfile, and better-aligns with user expectations. See here for an update on this struck-through portion.

What value is best for the default priority is debatable.

• The max is 32767, but we should leave room to allow for swap devices external to Swapspace (like a swap partition, which many distros create during installation, and which users may be stuck with when they start using Swapspace).
• The default is to use the highest available negative number, which should only be used for hibernation swapfiles.
• The minimum configurable value is 0, so we should target a Swapspace min of 0.

If we are only creating up to the 32 swap devices the kernel permits, then having the default priority be 31 will maximize economy.

If this is implemented, then #45 will need to become priority-aware.

[MilesBHuff]

To simplify things, the names of the swapfiles could theoretically be changed to match their priorities.

[MilesBHuff]

Apparently, not setting a priority is the same thing as setting negative priorities successively lower. What this means is that Swapspace is not, as I assumed, currently creating all of its swapfiles with the same priority; rather, it is in order from newest-to-oldest, but in a way that conflicts with hibernation. Swapspace should take charge of this itself, and explicitly define its priorities in a meaningful way.

The hibernation issue can be fixed by creating all Swapspace swapfiles with priority 0, and then the issues that come from having all swapfiles be the same priority (explained in the struckthrough part of my OP) can be resolved by implementing the suggestion in this issue when there is time to do so.

[Tookmund]

Would be willing to consider a patch changing this behavior, but this would come with significant testing requirements (that I would be happy to run myself to be clear, not requiring work from the contributor here). Would probably also want to confirm that priority has been a feature of swap since as far back as we can reasonably support, as far I as I can tell it is, but have not yet been able to find a definitive answer on that point.