lkml.org 
[lkml]   [1998]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New Feature Idea: Compress swap file

This has been done before.. My NeXT does it.. And I believe thats how
'ram' doubler products work.

I would suggest you use LZO. It's compression isn't bad, it's not
patented, and it decompresses fast as hell (like 40megsbytes/s on a
166mmx).. It's compression speed is tunable as a cratio/cspeed tradoff..
(So you might want to use different compression levels for differnt types
of data)..

Furthermore, LZO requires very little overhead memory wise..

On Thu, 19 Feb 1998, Adam Heath wrote:

> How about, when using swap, it is compressed before it is written out?
>
> It could be a two stage process, however, so as not to slow down performance.
> Ie, a page needs to be swapped. First, it is written to a small, static
> buffer(256k seems good. Should be dependent on physical ram size and page
> size. Also might be useful to have it variable in size, like the disk
> cache). If the machine is under heavy mem load, then eventually this buffer
> will fill and need to be swapped. This is no change from previous behaviour.
>
> However, when scheduling permits, the code can compress the buffer, and
> optionally reread already swapped out, uncompressed pages to compress them.
>
> This compress code could be optimized to only not compress executable pages,
> as those don't always compress that well.
>
> PS: The buffer would have low and high water marks, for both
> swapping/compressing. Above the low_swap(size), it would start swapping as
> time permitted. When above the high_swap, force swap until down to the
> low_swap. When idle, do nothing. Below the low_compress(cpu usage), compress
> the in-memory buffer. When below the high_compress, read in
> uncompressed/swapped out pages into the buffer, but don't nescessarily
> compress them yet(Cpu usage might suddenly spike back up, so wait and schedule
> the compression in the low_compress loop).
>
> Also, with this double buffer technique, Performance could increase, even if
> compression is not used. Ie, buffer fills(but not overflows), and some pages
> start to get swapped. However, they are not cleared from the buffer. If the
> pages are then needed, then can be fetched from the buffer, without waiting
> for the disk. This would, of course, also be applied to in memory compressed
> pages.
>
> And, one last thought. The buffer management would not need to actually copy
> the pages in memory. Just remap them to its own control(this would almost
> alleviate the need for a separate buffer).
>
> Obviously, it is too late in 2.1 to have this for 2.2. But inclusion with 2.3
> would be reasonable.
>
> I don't know enough about compression/swap to start something like this, but
> if I got some pointers, and guidance, I would be willing to help.
>
> Adam.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.072 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site