We have done it about 3 years ago, and it worked on the (then :) freshly
released version 1.1.0. We have not ported it to recent versions, which
I believe would be the same as rewriting it from scratch. About a year
ago somebody said they would be porting it to a recent kernel, but I
haven't heard of them ever since. I can look their addresses if somebody
cares...
The (ancient) distribution can be found at
http://gsd.di.uminho.pt/~jop/rswap/
if you care to take a look.
> > After hearing about some theoretical figures that said it would be a
> > performance increase swapping to the net (compared with swapping to local
> > disc) when you have a couple of boxes in a local net (even on 10MBit/s) I
> > thought about implementing this (if possible due to the deadlock problems
> > you mention) in two user-space processes, one to swap out data on the net
We did in fact see a big speedup over the regular disk swapper with out
user
level swapper, both to net and to disk. I believe that nowadays this
would not
happen as swapping code has improved a lot. The problem was that the
kernel
waited for a page to be fully written before selecting the next one.
> You can not have program which cares for swapping on client as user-level:
> What if it gets swapped out?
Our kernel patch implemented a device driver through which user level
programs
could act as swappers. To test this, we implemented both a disk swapper
and
a network swapper. The network swapper was just a simple client-server
built with rpcgen. The server stored the pages in memory. The disk
swapper could
grow swapfiles dynamically.
The problem with swapping out the swapper was solved by using a bit
in the task structure to signal unswappable processes. This was used
also
for init, as if a user level swapper process died, all processes that
requested pages from that swapper would be killed and killing
init is not nice at all.
In short, most of the changes to the kernel were needed to allow a
swapper
to fail, as it was assumed that it wouldn't. I don't know if this
situation
still holds.
> > I would apreciate any comments and ideas -- I've just recently begun
> > thinking about this and could possibly be fundamentally wrong about
> > something.
One important point in our work had to do with the messaging between the
kernel and the user process. As I said, it was disguised as a character
device, and it carried just short messages containing page info
and pointers. The pages themselves were never copied, they were unmapped
from the sender and mapped in the receiver in a rather Mach'ish way.
We also tweaked the scheduler, so when a message was put in the
device queue, the target process was waked up right away (this may
no longer be an important issue, as the scheduler has also improved
a lot since then). This optimizations made a message cost less
than 100us in a 486DX2 when an SysV IPC message would take more than
300us. IPC performace would also degrade faster with system load.
If it want to hear more about it, please email me.
-- Jose Orlando Pereira * jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *