Re: [PATCH v7 11/12] zsmalloc: page migration support

On Tue, Jan 24, 2017 at 11:06:51PM -0500, Chulmin Kim wrote:

On 01/23/2017 12:40 AM, Minchan Kim wrote:

quoted

On Mon, Jan 23, 2017 at 02:30:56PM +0900, Sergey Senozhatsky wrote:

quoted

On (01/23/17 14:22), Minchan Kim wrote:
[..]

quoted

quoted

Anyway, I will let you know the situation when it gets more clear.

Yeb, Thanks.

Perhaps, did you tried flush page before the writing?
I think arm64 have no d-cache alising problem but worth to try it.
Who knows :)

I thought that flush_dcache_page() is only for cases when we write
to page (store that makes pages dirty), isn't it?

I think we need both because to see recent stores done by the user.
I'm not sure it should be done by block device driver rather than
page cache. Anyway, brd added it so worth to try it, I thought. :)

Thanks for the suggestion!
It might be helpful
though proving it is not easy as the problem appears rarely.

Have you thought about
zram swap or zswap dealing with self modifying code pages (ex. JIT)?
(arm64 may have i-cache aliasing problem)

It can happen, I think, although I don't know how arm64 handles it.

If it is problematic,
especiallly zswap (without flush_dcache_page in zswap_frontswap_load()) may
provide the corrupted data
and even swap out (compressing) may see the corrupted data sooner or later,
i guess.

try_to_unmap_one calls flush_cache_page which I hope to handle swap-out side
but for swap-in, I think zswap need flushing logic because it's first
touch of the user buffer so it's his resposibility.

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>