[Galaxy S III Android Development] agusdallalba:
[MENTION=4898097]arter97[/MENTION]: Sorry if this becomes too long. I just wanted to write down all I've researched about this. The replies are hidden in spoilers so that everyone else doesn't have to scroll endlessly :P

Not quite! zram works as a "normal" swap device. In your example, nothing will get compressed until you fill up the entire 1GB of ram. (Note that this includes file system caches and such) Only then will the kernel (essentially) choose a piece of RAM that hasn't been read for a long time and send it to swap. If your only swap device is a zram device, it will get compressed in RAM instead of written somewhere else. But this has a few inefficiencies, mostly because zram has to act like a normal swap device:

If you set up both a zram and a traditional swap device, once the former is full it won't be used again, and since the kernel will swap first memory that's rarely touched, you end up with a (fast) zram full of things that rarely get used while the performance-critical things go to the (slow) traditional swap.

If the data in memory is not very compressible (like game textures), all this compress-then-decompress-then-compress dance is pretty useless, but zram can't 'reject' data that doesn't compress well to make room for 'nicer' data.

Its memory usage is unpredictable. Your example zram appears as a 500MB block device, but it might take anything from a few MB to the full 500 of memory when full depending on how compressible the data that it holds is.

Enter frontswap: A new (in Linux 3.0) type of swap device that's a lot more flexible than the traditional block-based one and solves all those problems. It doesn't show up in /proc/swaps. Unlike the block-based swaps, a frontswap does not have a fixed size, and it can reject pages any time it wants, even those that it had accepted before. All swapped pages go to the frontswap first, however, because a particular implementation may suddenly reject everything, every page must have a place to go in a regular, block-based swap just in case. What's important is that a frontswap cannot affect how a page is written to a regular swap device, it's separate from those

zswap is a frontswap driver. And it stores the data that the kernel handles to it compressed

in RAM

. It also gets rid of 'stale' unused pages by itself when it's running tight, and refuses to store pages that can't be compressed. Check the Arch wiki about it:

It doesn't seem so weird to me. That's for example how the initramfs is implemented (but again, I don't know how to test it here!):

What's more, and this is new to me, that behaviour seems encouraged in the frontswap documentation! (If only Samsung had left such a comprehensive documentation, we wouldn't have to be discussing this if they had)

Are you talking about vnswap_find_free_area_in_backing_storage(int *nand_offset)? The name is misleading, what it scans is the vnswap -> real file map it made before to find a "hole", and then outputs the nand_offset that corresponds to that place in the file. It does this linearly starting from the place it last wrote something. If it doesn't find anything it returns a "No space left in device" error.

The map, as far as I can tell, is set up in vnswap_init_backing_storage(), that scans where all the pieces of the file in the variable 'backing_storage_file' reside in NAND, among other things. This variable is initially set null and the only other place I can see it being set is in /sys/block/vnswap0/swap_filename.

What I'm missing is the 'magic link' between the vnswap device and the NAND. The only one I see is that backing_storage_file, which is unset in my phone by default. But then again all the 'bio' functions are too complicated for me: I'm not very familiar with the kernel, and the link could well be there. Please tell me if you find anything :)

Maybe Touchwiz features the first completely random and incompressible memory leak in the history of computing so they decided to stash it to NAND instead of fixing it. :D :D :D

Indeed, thanks for listening :good: