Riccardo> Imagine you have an application that is asking for
Riccardo> memory and all the available memory is exhausted. In
Riccardo> this case malloc return NULL and your application will
Riccardo> bomb out (gracefully for itself or with SEGV or
Riccardo> something like that). In a case like this, the sysadmin
Riccardo> will likely not have time to add more swap by hand
Riccardo> before applications start to bomb out.
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 !
Digging further more, the dream would be to have *all* of the unused
local disk space available for swap. Then, no need to do anything
manually, except, maybe, adding a disk :-)
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.
Anyway, the swap partition would probably not die. It could be used
the usual way for standard swapping. The "rest of the disks" swap
area would only be used in *heavy* swapping condition as it will be
slower, because of the file-system layer.
Thus, we'd obtain 2-level swap.
Here, I'm totally anaware of the overhead of such design, or, further
more, of the impact on existing sources ... Could someone comment ?
Herve Regad-Pellagru
Big Gray Wall: n. What faces a VMS user searching for documentation.
A full VMS kit comes on a pallet, the documentation taking up around
15 feet of shelf space before the addition of layered products such as
compilers, databases, multivendor networking, and programming tools.