On Mon, Aug 30, 2010 at 8:30 AM, Stefan Monnier <span
dir="ltr"><monnier@iro.umontreal.ca></span> wrote:<br />
<div class="gmail_quote"><blockquote style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"
class="gmail_quote">
<div class="im">> Because of this, I wondered if compcache ever looked
in the direction of<br /> > compressed swapping to nand, specifically
to SD.<br /> <br /> </div>
While SD uses nand internally, it can only be accessed via a
translation<br /> layer that completely hides the nand's features, so you
can't do much<br /> better than treat it as a normal drive, and just try
and avoid writing<br /> too much/often to it.<br /> <br /> I.e. the
support for SD can't be improved (except by tuning down the<br />
swapiness of the kernel).<br /><br /></blockquote></div>
<br /> SD does hide NAND's features behind a translation layer, but
it is still susceptible to the performance hit of NAND's erase block
size. If you buffer and commit contiguous writes at the size of the
SD/NAND's erase block, you increase write performance. If you
commit data smaller than the erase block size, the SD device must read
all data in the erase block, merge the smaller data portion, erase the
block, and then write it all back out. If an erase block is 128KB,
committing 4KB is going to take nearly the same amount of time as
committing 128KB -- so you may as well commit 128KB! Buffering and
remapping swapped pages into contiguous commits that are the size of the
underlying NAND's erase block size should greatly increase write
performance for NAND based block devices. Compcache appears to
tackle some remapping already, just not the buffering into erase block
sized commits.<br /> <br /> In addition -- speaking directly
to "avoid writing too much/often to it" -- if you compress
data before writing, you also decrease the I/O penalty of read/writes to
the relatively slow block device. Further, (assuming there is
enough processing power to spare) keeping a "unique" hash table
in ram of previously swapped pages could conceivably eliminate re-writing
duplicate pages back out to a slow block device over and over. This
would, of course, require keeping swapped pages on the block device for
as long as possible -- even after being swapped back into ram --
requiring a much larger swap file/partition on the block device than the
extra memory space you are looking to achieve. How much more would
depend on the work-load.<br /> <br /> I still can't help but
think there is room for dramatically increasing performance with
swapping to NAND based block devices, even if behind a translation
layer. In fact, SD's translation layer is beneficial in that it
should take care of wear leveling for you. The same holds true for
SSDs and many other block device based on NAND.<br />