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

[Minchan Kim <minchan@kernel.org>]

On Tue, Jan 24, 2017 at 11:06:51PM -0500, Chulmin Kim wrote:
> On 01/23/2017 12:40 AM, Minchan Kim wrote:
> >On Mon, Jan 23, 2017 at 02:30:56PM +0900, Sergey Senozhatsky wrote:
> >>On (01/23/17 14:22), Minchan Kim wrote:
> >>[..]
> >>>>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>