That is one reason why I try to have swap on a device dedicated just for it.
It helps keep the system from having to seek all over the drive for data. (I
remember that this was recommended years ago with Windows - back when you
could tell Windows where to put the swap file)
For it to really help swap-prefetch would have to be more aggressive. At the
moment (if I'm reading the code correctly) the system has to have close to
zero for it to kick in. A tunable knob controlling how much activity is too
much for the prefetch to kick in would help with finding a sane default. IMHO
it should be the one that provides the most benefit with the least hit to
performance.
Maybe. It all depends on how much seeking is needed to track down the pages in
the swapfile and such. What would really help make the situation even better
would be doing the log structured swap + cleaner. The log structured swap +
cleaner should provide a performance boost by itself - add in the prefetch
mechanism and the benefits are even more visible.
Another way to improve performance would require making the page replacement
mechanism more intelligent. There are bounds to what can be done in the
kernel without negatively impacting performance, but, if I've read the code
correctly, there might be a better way to decide which pages to evict. One
way to do this would be to implement some mechanism that allows the system to
choose a single group of contiguous pages (or, say, a large soft-page) over
swapping out a single page at a time.
(some form of memory defrag would also be nice, but I can't think of a way to
do that without massively breaking everything)
<snip>
The userspace suggestion that was thrown out earlier would have been as
error-prone and problematic as FUSE. A solution like you suggest would be
workable - its small and does a task that is best done in userspace (IMHO).
(IIRC, the original suggestion involved merging maps2 and another patchset
into mainline and using that, combined with PEEKTEXT to provide for a
userspace swap daemon. Swap, IMHO, should never be handled outside the
kernel)
What might be useful is a userspace daemon that tracks memory pressure and
uses a concise API to trigger various levels of prefetch and/or swap
aggressiveness.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
