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.
I'd be quite strongly against an additional system call: if we're
going to speed it up, let's speed up the common case, not your special
additional call. But I don't think you need that anyway: the slowness
doesn't come from the limited number of swap areas, but from the much
greater numbers of processes and their pages. Looping over the number
of swap areas (so often 1) isn't a problem.
I'll ignore your steps 1 and 3, I don't see the advantage. (We
do already prevent pages from being swapped out to the area we're
swapping off, and in general we need to allow for swapping out to
another area while swapping off.) Step 2 is the core of your idea.
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, except in those (exceptional, I'm afraid) cases where almost
all the swap pages are already in core swapcache when swapoff begins.
Well, do give it a try if you're interested: I've never actually
timed doing it that way, and might be surprised. I doubt you could
actually remove the present code, but it could become a fallback to
clear up the loose ends after some faster first pass.
Don't forget you'll also need to deal with tmpfs files (mm/shmem.c):
Christoph Rohland long ago had a patch to work on those in the way you
propose, but we never integrated it because of the random seek issue.
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).
Hugh
-
