zcache: a compressed page cache
Like its predecessors, zcache lives to store compressed copies of pages in memory. It no longer looks like a swap device, though; instead, it is set up as a backing store provider for the Cleancache framework. Cleancache uses a set of hooks into the page cache and filesystem code; when a page is evicted from the cache, it is passed to Cleancache, which might (or might not) save a copy somewhere. When pages are needed again, Cleancache gets a chance to restore them before the kernel reads them from disk. If Cleancache (and its backing store) is able to quickly save and restore pages, the potential exists for a real improvement in system performance.
Zcache uses LZO to compress pages passed to it by Cleancache; only pages which compress to less than half their original size are stored. There is also a special test for pages containing only zeros; those compress exceptionally well, requiring no storage space at all. There is not, at this point, any other attempt at the unification of pages with duplicated contents (as is done by KSM), though.
There are a couple of obvious tradeoffs to using a mechanism like zcache: memory usage and CPU time. With regard to memory, Nitin says:
The current patch does allow the system administrator to manually adjust the size of the zcache area, which is a start. It will be a rare admin, though, who wants to watch cache hit rates and tweak low-level memory management parameters in an attempt to sustain optimal behavior over time. So zcache will almost certainly have to grow some sort of adaptive self-tweaking before it can make it into the mainline.
The other tradeoff is CPU time: it takes processor time to compress and
decompress pages of memory. The cost is made worse by any pages which fail
to compress down to less than 50% of their original size - the time spent
compressing them is a total waste. But, as Nitin points out: "with
multi-cores becoming common, benefits of reduced disk I/O should easily
outweigh the problem of increased CPU usage
". People have often
wondered what we are going to do with the increasing number of cores on
contemporary processors; perhaps zcache is part of the answer.
One other issue remains to be resolved, though: zcache depends on
Cleancache, which is not currently in the mainline. There is some opposition to merging Cleancache, mostly
because that patch, which makes changes to individual filesystems, is seen
as being overly intrusive. It's also not clear that everybody is, yet,
sold on the value of Cleancache, despite the fact that SUSE has been
shipping it for a little while now. Until the fate of Cleancache is resolved, add-on
patches like zcache will be stuck outside of the mainline.
Index entries for this article | |
---|---|
Kernel | Memory management/Swapping |
Kernel | Transcendent memory |
Posted Jul 29, 2010 6:45 UTC (Thu)
by Tara_Li (guest, #26706)
[Link] (7 responses)
Posted Jul 29, 2010 10:01 UTC (Thu)
by saffroy (guest, #43999)
[Link] (6 responses)
Without compression, I/O can occur with little participation of the CPU, which "only" has to setup data structures, do a bit of device I/O, and let the DMA process all data while the CPU can do other useful stuff for you. Of course, uncompressed data is larger, and take more time to read or write, but that's not the whole story.
With compression, the CPU has to process each and every byte of data that's read or written. Your compression algorithm has better be fast and efficient on your data. And you consume a LOT more CPU time than before, and some more memory bandwidth, and you also probably trash your memory caches heavily. And you may drain your laptop battery faster too (depends which of large disk I/O vs. compression+small I/O needs more power).
Now I definitely support the idea of compressing data before I/O, it's just that it has to be carefully thought out in order to be a definite improvement, it does not work equally well on every workload. For instance, I bet the bitmaps of the photos I'm editing in the Gimp are hard to compress fast; how will the kernel know that it should probably not try to compress them?
Posted Jul 29, 2010 23:56 UTC (Thu)
by jzbiciak (guest, #5246)
[Link] (5 responses)
Hard drive seek times are measured in multiple milliseconds. 1ms is 1 million cycles on a 1GHz CPU. You can do a lot in that time. For every seek you eliminate, you buy back millions and millions of CPU cycles.
As for your GIMP working set? The main gain you'll get there is from the other data in your system compressing, making room for GIMP. And besides, GIMP does its own paging via its tile cache, doesn't it?
Posted Jul 30, 2010 20:09 UTC (Fri)
by joern (guest, #22392)
[Link] (4 responses)
Wrt. swap, compression may well end up reducing seeks. But for file backed data, compression costs a lot more performance than the cpu cycles spent in zlib or whereever.
Posted Jul 31, 2010 3:00 UTC (Sat)
by jzbiciak (guest, #5246)
[Link] (2 responses)
If you take hitting the disk as a given, as is the case with a compressed filesystem with compressed files, then the tradeoffs get much more complex. This is especially true whenyou consider that most files are small relative to disk block sizes.
But with VM, it's about dirty anonymous pages (heap and such). The only reason to push these to disk is that you're trying to use more RAM than is available. Disk acts as RAM overflow. If compression can push the "swap to disk" threshold out, then it is a clearer win.
Posted Jul 31, 2010 6:42 UTC (Sat)
by saffroy (guest, #43999)
[Link] (1 responses)
Interesting. Got more details or pointers about this?
Posted Jul 31, 2010 14:34 UTC (Sat)
by jzbiciak (guest, #5246)
[Link]
That at least illustrates the principle that compression can keep you from hitting the disk and also increase the size of workload a machine can handles effectively.
Posted Jul 31, 2010 3:04 UTC (Sat)
by jzbiciak (guest, #5246)
[Link]
Posted Jul 29, 2010 13:56 UTC (Thu)
by edt (guest, #842)
[Link]
Posted Jul 30, 2010 9:19 UTC (Fri)
by juanjux (guest, #11652)
[Link]
Posted Aug 7, 2010 4:09 UTC (Sat)
by nwmcsween (guest, #62367)
[Link]
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache
zcache: a compressed page cache