First, it's worth pointing out that some people will try to claim that swapping to an SSD is a bad idea. This used to be the case when SSD's were heavily write limited, but is not the case these days (most SSD's are rated at more than one thousand times their capacity for write endurance, and a swap file will typically be a tiny fraction of the capacity), and even less so if you're not swapping regularly and you should not be swapping regularly on any modern system). As a somewhat concrete example, a typical 250GB SSD these days is rated at well over 100TB of writes. With default swap behavior and typical desktop or server usage on a properly provisioned system, you'll average a few MB of swap usage in a day, which translates to less than 1/100000 of the device's rating. Additionally, most of the issues can be mitigated by specifying the
discard option in the
/etc/fstab entry for the swap region (or adding
-d to the
Second, it's not technically possible to boost perceived performance by interleaving swap devices like this (which is what you appear to want to do based on your reply to this answer). This is most easily illustrated with an analogy: Assume you have two people who offer to store things for you, one can store lots of things very quickly, and return them to you very quickly too, while the other can only store a few things, and is much slower. If you just need to store a very large group of things all at once, and only need to get it all back at once, the optimal method is to give out proportionate numbers of items to each such that it takes them the same amount of time to store what they've been given. However, this strategy falls apart if you need to store and retrieve individual items, because you will end up wasting time with the slow person on occasion. In that case, the optimal method is to give the fast person things you will need to store and retrieve frequently, and the slow one things you won't need very often.
Swapping to disk is like the second case, with two added constraints, you have no idea what you are going to need frequently and what you won't (you can get some idea from actual system usage, but doing this is very difficult, and as a result, nothing does this), and you have no idea how much you will need to store. In this case, it's most efficient to store everything with the fast person as long as they have room, and store the excess with the slow person.
Given this, it's better in almost all cases to prioritize swapping to the SSD to the exclusion of the hard drive. Thankfully, doing that is actually really easy with Linux. Swap space (both files, and partitions) can have reasonably arbitrary priorities that dictate the preferred order of usage. These are set with the
-p option to
swapon, and the
prio= option in
/etc/fstab. By default, everything has a priority of -1, which means that they get used in the order they were enabled. By setting a priority higher than negative one, you can control what order things get used in. Swap regions with higher priorities (up to 32767 max) will be used before ones at lower priorities, and regions with the same priority will be used in a round-robin fashion (kind of like a RAID0 setup, but with a larger chunk granularity, and no parallelization).
Assuming you're still certain that you want to put some of your data on the slower device even if there is space on the faster one, you can also achieve this with priorities by setting all the regions to the same priority higher than -1, but you will unfortunately need multiple files to do so (in theory, you could get really creative with loop devices or device-mapper targets, but that really is more trouble than it's worth).
Somewhat off-topic, but do make sure your swap files are owned by the root user and group, and are only readable and writable by root, otherwise arbitrary users may be able to trivially crash your system (or access data they shouldn't).