Re: swap space: an idea. Please comment.

Thomas Schoebel-Theuer (
3 Mar 1997 13:09:19 GMT

In article <199703022012.VAA09851@ford.home>, "Herve R.-P." <> writes:
|> >>>>> "Riccardo" == Riccardo Facchetti <> writes:
|> Riccardo> Now the idea. Why not have an (I called) "adaptive" or
|> Riccardo> if you prefer (I don't :) "dynamic" swap file, managed
|> Riccardo> in kernel space, that can grow and shrink when memory is
|> Riccardo> needed and/or released by someone ?
|> Fine, indeed !
|> Of course, fragmentation problems occur, here. It would be necessary
|> to keep swap pages to the lowest block numbers of the disk and files
|> to the highest. A sorted list of ununsed blocks for the filesystem
|> *and* for the swap would probably help.

I like the idea of having dynamic swap, as is for example possible in HP-UX.
The size of a swapfile can be dynamically changed according to some
limits (min/max etc.).

If you like to implement it, my advice is not to fundamentally change
anything that is available today. I.e., don't introduce a new file system
with reserved space for swap, but use the current swapfile mechanism.
Is is slower than directly swapping to partitions, but it can be made
dynamic in contrast to the latter.

I see the following tasks:

a) Remove the 128 MB limit on swapfiles.
b) modify mkswap to maintain existing swapfiles (that are even actively
swapped to), i.e. statically changing (at least increasing) the size,
set/change limits, and memorize that in the swapfile header.
c) changes in the kernel to obey the new swapfile headers will be minimal.
d) write a daemon that dynamically calls mkswap when memory goes short.
Ensure that the mkswap process has always enough memory to perform
its task.

I think this solutions will be more modular than doing all stuff in the
kernel. The problem is that creating swapfiles is already outside
the kernel, and increasing size can be seen as a subtask of it, so you
would have to basically re-implement mkswap in the kernel if you
dont like a daemon solution. On the other hand, such a daemon needs
a higher "memory priority" that has also to be implemented.
But perhaps such a concept is lacking anyway, and should be implemented
more generally.

For decreasing the swapfile size, I'd suggest to remember the desired size
along with the maximum allocated block number. Each time the maximum block
is deallocated, the actual size can be reduced accordingly.

-- Thomas