I understood, in my original post, that compressing a page would take cpu
time, and if memory was short, that the system my be too sluggish. But please
reread the post. I suggested a two-stage process. The VMM says "swap pages
1-10". The swapper maps them into a hold buffer, and does nothing, neither
compress or io. In the kernel idle loop, a compression is done to the in
memory copy. When physical swapping occurs, it can write out both the
already compressed pages, and uncompressed. If swap space starts to get
tight, then swapped uncompressed pages could be reread and compressed in
order to gain memory. If the system is busy, pages would just be swapped
out uncompressed, with no loss in performance. Only when the system is IDLE,
would pages be compressed.
Obviously, sometimes the swapping io would need to be expediated(sp?), so as
to free memory. And, it is assumed that any compression code developed would
decompress fast. Also, if the kernel implemented pre-swapping, then
pre-compressing would also follow.
Also, in the kernel idle loop, previously swapped, uncompressed pages could be
reread into the temporary buffer, so as to be compressed the next time thru
the idle loop.
As has been mentioned, code pages aren't swapped, but discarded(a plus).
Kernel code is not currently swapped(that I know of), so there shouldn't be
DMA buffer problems.
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu