[linux-mm-cc] Compressed swapping to nand memory

[John Kielkopf]

On Mon, Aug 30, 2010 at 8:30 AM, Stefan  Monnier <monnier at iro.umontreal.ca> wrote:


>  Because of this, I wondered if compcache ever looked
in the direction of
 > compressed swapping to nand, specifically
to SD.
 
 
While SD uses nand internally, it can only be accessed via a 
translation
 layer that completely hides the nand's features, so you
can't do much
 better than treat it as a normal drive, and just try
and avoid writing
 too much/often to it.
 
 I.e. the
support for SD can't be improved (except by tuning down the

swapiness of the kernel).



       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.
       
       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.
       
      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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20100830/8ffdcd33/attachment.htm