Messages in this thread | | | From | "Russell Coker - mailing lists account" <> | Date | Sat, 21 Feb 98 23:36:43 +1000 | Subject | Re: New Feature Idea: Compress swap file |
| |
> - Our objective is performance, by reducing the amount of read/write to the >swap;
Also reduces the size of swap in use which provides more usable VM for a given amount of disk space, however this makes swap requirements less predictable (the system could run out of memory by changing some data to less regular patterns). If we reduce the amount of swap space required then we should reduce the amount of seeking done to access swap, as well as decreasing the data transfers. If we can compress a page to less than the sector size is it worth while? If we have a page compressed to 256 bytes then we can fit another 256 byte page in the same disk sector, if we have to read the sector in before writing are we gaining anything? Perhaps we could just store such easily compresible pages in memory first where we could retrieve them rapidly by decompression. Then if we decide to finally send the data to disk we can do it 2 pages at a time so we can do a single sector write to store 2 pages (this seems good). However if one of those pages gets accessed again then we end up with a sector containing a page which is compressed to <256 bytes and which has 256+ bytes free, but I guess even if such fragmentation becomes rampant we still win by having such a page take 512 bytes instead of 4K or 8K (depending on the platform). Also some time ago Ingo Molnar wrote a patch to count swap-outs of pages which were filled with zeros. It was found that the systems tested had around 1% of pages filled with zeros. There was discussion about writing a patch to check for zero pages and make them the copy-on-write zero page, but it was decided that it wan't worth while. If we install swap compression then checking for zero pages would be a trivial part of the work and probably would be worth-while. It'd also make some fortran programmers happy...
> - We can minimize the time wasted on compression by not compress code >pages, only > data pages. What's the (normal expected) relation of code/data pages?
Currently we don't swap out code pages, we discard them. There has been talk of adding a feature whereby code pages from slow devices (NFS and CD-ROM) could be paged out to a fast local disk. AFAIK nothing concrete has been done about it though.
Russell Coker
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |