| |||||||||||||
Compcache: in-memory compressed swappingCompcache: in-memory compressed swappingPosted May 28, 2009 8:23 UTC (Thu) by jimparis (subscriber, #38647)Parent article: Compcache: in-memory compressed swapping
How does compcache differ in concept from, say:
- use mtdram driver to make a MTD device out of ram - use jffs2 with compression enabled on the new mtd device - put a swapfile on that filesystem and swap to it Is there a fundamental reason that this wouldn't work and compcache is needed, or is compcache just trying to remove some of those layers?
(Log in to post comments)
Compcache: in-memory compressed swapping Posted May 28, 2009 8:45 UTC (Thu) by amikins (guest, #451) [Link]
More layers of indirection will result in notably more processing per action. Making a specialty 'device' with fewer features and simpler assumptions about usage allows you to cut a lot of significant corners.
I'd be -very- interested in some measurements of the difference between the 'existing possible' approach and compcache..
Compcache: in-memory compressed swapping Posted May 29, 2009 4:29 UTC (Fri) by nitingupta (subscriber, #53817) [Link]
How does compcache differ in concept from, say:
> - use mtdram driver to make a MTD device out of ram
mtdram driver simply simulates MTD device in ram - no compression and no memory management (it simply preallocates all the memory). Also, there are unnecessary overheads involved -- simulate erasing eraseblock and such.
> - use jffs2 with compression enabled on the new mtd device
Base for this indirection hierarchy is the in-ram mtd device which has problems mentioned above. Also, as amikims pointed out, additional levels of indirection means more overhead.
Compcache: in-memory compressed swapping Posted Jun 12, 2009 19:10 UTC (Fri) by bluefoxicy (guest, #25366) [Link]
I've tried using the device mapper. It tends to deadlock if you try to device map a file on a tmpfs and create swap partitions on it.
|
|||||||||||||