I see some minor issues with what I think you mean:
1) Programs _never_ enter the swap. (At least ELF-executables) So there
is nothing to win here, unless you want to _write_ an executable to disk
first before reading it (which effectively gains probably nothing)
2) The current swap-code is efficient because it uses a _fixed_ granularity
(eg one page, 4k or 8k). Disks like this. Unless you are using a
fixed-to-fixed block-encoding algorithm, compression loses this property.
3) For swapping over the network: A compressed network-protocol would gain
MUCH more, not only swapping but for normal traffic also.
4) In your timings, you assume there is one physical disk. If there are
more, Linux spreads the load amoung them and is able to achieve much
higher bandwidths.
5) Reserving a fixed piece of memory loses the flexibility the current
kernel has in splitting the "spare" memory amoung cache/data/programs
in an optimal way
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/