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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 30, 2017 at 7:10 PM, Minchan Kim <minchan@xxxxxxxxxx> wrote:
> Hi Dan,
>
> On Thu, Jan 26, 2017 at 12:04:03PM -0500, Dan Streetman wrote:
>> On Wed, Jan 25, 2017 at 12:26 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote:
>> > 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.
>>
>> Hmm, I don't think zswap needs to, because all the cache aliases were
>> flushed when the page was written out.  After that, any access to the
>> page will cause a fault, and the fault will cause the page to be read
>> back in (via zswap).  I don't see how the page could be cached at any
>> time between the swap write-out and swap read-in, so there should be
>> no need to flush any caches when it's read back in; am I missing
>> something?
>
> Documentation/cachetlb.txt says
>
>   void flush_dcache_page(struct page *page)
>
>         Any time the kernel writes to a page cache page, _OR_
>         the kernel is about to read from a page cache page and
>         user space shared/writable mappings of this page potentially
>         exist, this routine is called.
>
> For swap-in side, I don't see any logic to prevent the aliasing
> problem. Let's consider other examples like cow_user_page->
> copy_user_highpage. For architectures which can make aliasing,
> it has arch specific functions which has flushing function.

COW works with a page that has a physical backing.  swap-in does not.
COW pages can be accessed normally; swapped out pages cannot.

>
> IOW, if a kernel makes store operation to the page which will
> be mapped to user space address, kernel should call flush function.
> Otherwise, user space will miss recent update from kernel side.

as I said before, when it's swapped out caches are flushed, and the
page mapping invalidated, so it will cause a fault on any access, and
thus cause swap to re-load the page from disk (or zswap).  So how
would a cache of the page be created after swap-out, but before
swap-in?  It's not possible for user space to have any caches to the
page, unless (as I said) I'm missing something?


>
> Thanks.

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux