"My experiments show that when there is not much free physical memory, swapoff moves pages out of swap at a rate of approximately 5mb/sec," Daniel Drake noted in a recent discussion about swapoff performance. He added, "I've read into the swap code and I have some understanding that this is an expensive operation (and has to be)." Hugh Dickins acknowledged, "Yes, it can be shamefully slow. But we've done nothing about it for years, simply because very few actually suffer from its worst cases. You're the first I've heard complain about it in a long time: perhaps you'll be joined by a chorus, and we can have fun looking at it again."

As a potential optimization Daniel proposed, "iterate through all process page tables, paging all swapped pages back into physical memory and updating PTEs". Hugh replied, "feasible yes, and very much less CPU-intensive than the present method. But... it would be reading in pages from swap in pretty much a random order, whereas the present method is reading them in sequentially, to minimize disk seek time. So I doubt your way would actually work out faster". He then added:

"The speedups I've imagined making, were a need demonstrated, have been more on the lines of batching (dealing with a range of pages in one go) and hashing (using the swapmap's ushort, so often 1 or 2 or 3, to hold an indicator of where to look for its references)."