Messages in this thread | | | From | (Thomas Schoebel-Theuer) | Subject | Re: swap space: an idea. Please comment. | Date | 3 Mar 1997 13:09:19 GMT |
| |
In article <199703022012.VAA09851@ford.home>, "Herve R.-P." <regad@micronet.fr> writes: |> >>>>> "Riccardo" == Riccardo Facchetti <fizban@mbox.vol.it> 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
| |