swapping file pages

swapping file pages

[Luigi Semenzato]

On an SSD used by a typical chromebook (i.e. the one on my desk right
now), it takes about 300us to read a random 4k page, but it takes less
than 10us to lzo-decompress a page from the zram device.

Code compresses reasonably well (down to almost 50% for x86_64,
although only 66% for ARM32), so I may be better off swapping file
pages to zram, rather than reading them back from the SSD.  Before I
even get started trying to do this, can anybody tell me if this is a
stupid idea?  Or possibly a good idea, but totally impractical from an
implementation perspective?

Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: swapping file pages

[Minchan Kim]

Hello Luigi,

On Fri, Apr 21, 2017 at 11:26:45AM -0700, Luigi Semenzato wrote:
> On an SSD used by a typical chromebook (i.e. the one on my desk right
> now), it takes about 300us to read a random 4k page, but it takes less
> than 10us to lzo-decompress a page from the zram device.

IMO, it should be solved by VM itself rather than adding another layer
I mentioned below. IOW, If VM found file-backed page's reclaim/refaut
cost is higher than anonymous, VM should tip toward anonymous LRU.
I guess upcoming patches from Johannes's work would be key for the
issue.

> 
> Code compresses reasonably well (down to almost 50% for x86_64,
> although only 66% for ARM32), so I may be better off swapping file
> pages to zram, rather than reading them back from the SSD.  Before I
> even get started trying to do this, can anybody tell me if this is a
> stupid idea?  Or possibly a good idea, but totally impractical from an
> implementation perspective?

Although I believe it should be solved by VM itself in the long run,
I think cleancache might help you at this moment.

Please look at cleancache. It's hook layer of page cache so you can
compress pages dropped from page cache if FS supports cleancache_ops.
zcache was one of implementation for that. If the hit ratio is high,
it would be reasonable.

https://lwn.net/Articles/397574/

One of the problem at that time was cache miss ratio was too high
for stream-write workload because it have kept used-once pages
in the memory. It was pointelss.

Dan suggested PG_activated bit to detect pages promoted to active
LRU list for the life time and store only those pages in the
backend(ie, allocator) but he retired in the middle of the work.
Johannes's patch introduced PG_workingset which is same with
PG_activiated Dan suggested so maybe we can use the flag to avoid
overhead.

Another idea to use cleacache/frontswap although it didn't provide
cleancache backend at that time was GCMA. GCMA's main goal is
to guarantee get contiguous area in deterministic time. For that,
it used frontswap/cleancache concept.

http://events.linuxfoundation.org/sites/events/files/slides/gcma-guaranteed_contiguous_memory_allocator-lfklf2014_0.pdf

I hope it helps you a bit.

> 
> Thanks!
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>