Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Dan Streetman <ddstreet@ieee.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Chulmin Kim <cmlaika.kim@samsung.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH v7 11/12] zsmalloc: page migration support
Date: Tue, 31 Jan 2017 08:09:53 -0500
Message-ID: <CALZtONDQ5yQKV6-jpJGBg7gakV8-7XXmmAATSQq346Tby4WLsg@mail.gmail.com> (raw)
In-Reply-To: <20170131001025.GD7942@bbox>

On Mon, Jan 30, 2017 at 7:10 PM, Minchan Kim <minchan@kernel.org> 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@kernel.org> 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@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>

  reply index

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 23:21 [PATCH v7 00/12] Support non-lru page migration Minchan Kim
2016-05-31 23:21 ` [PATCH v7 01/12] mm: use put_page to free page instead of putback_lru_page Minchan Kim
2016-05-31 23:21 ` [PATCH v7 02/12] mm: migrate: support non-lru movable page migration Minchan Kim
2016-05-31 23:21 ` [PATCH v7 03/12] mm: balloon: use general non-lru movable page feature Minchan Kim
2016-05-31 23:21 ` [PATCH v7 04/12] zsmalloc: keep max_object in size_class Minchan Kim
2016-05-31 23:21 ` [PATCH v7 05/12] zsmalloc: use bit_spin_lock Minchan Kim
2016-05-31 23:21 ` [PATCH v7 06/12] zsmalloc: use accessor Minchan Kim
2016-05-31 23:21 ` [PATCH v7 07/12] zsmalloc: factor page chain functionality out Minchan Kim
2016-05-31 23:21 ` [PATCH v7 08/12] zsmalloc: introduce zspage structure Minchan Kim
2016-05-31 23:21 ` [PATCH v7 09/12] zsmalloc: separate free_zspage from putback_zspage Minchan Kim
2016-05-31 23:21 ` [PATCH v7 10/12] zsmalloc: use freeobj for index Minchan Kim
2016-05-31 23:21 ` [PATCH v7 11/12] zsmalloc: page migration support Minchan Kim
2016-06-01 14:09   ` Vlastimil Babka
2016-06-02  0:25     ` Minchan Kim
2016-06-02 11:44       ` Vlastimil Babka
2016-06-01 21:39   ` Andrew Morton
2016-06-02  0:15     ` Minchan Kim
     [not found]   ` <CGME20170119001317epcas1p188357c77e1f4ff08b6d3dcb76dedca06@epcas1p1.samsung.com>
2017-01-19  0:13     ` Chulmin Kim
2017-01-19  2:44       ` Minchan Kim
2017-01-19  3:39         ` Chulmin Kim
2017-01-19  6:21           ` Minchan Kim
2017-01-19  8:16             ` Chulmin Kim
2017-01-23  5:22               ` Minchan Kim
2017-01-23  5:30                 ` Sergey Senozhatsky
2017-01-23  5:40                   ` Minchan Kim
2017-01-25  4:06                     ` Chulmin Kim
2017-01-25  4:25                       ` Sergey Senozhatsky
2017-01-25  5:26                       ` Minchan Kim
2017-01-26 17:04                         ` Dan Streetman
2017-01-31  0:10                           ` Minchan Kim
2017-01-31 13:09                             ` Dan Streetman [this message]
2017-02-01  6:51                               ` Minchan Kim
2017-02-01 19:38                                 ` Dan Streetman
2017-02-02  8:48                               ` Minchan Kim
2016-05-31 23:21 ` [PATCH v7 12/12] zram: use __GFP_MOVABLE for memory allocation Minchan Kim
2016-06-01 21:41 ` [PATCH v7 00/12] Support non-lru page migration Andrew Morton
2016-06-01 22:40   ` Daniel Vetter
2016-06-02  0:36   ` Minchan Kim
2016-06-15  7:59 ` Sergey Senozhatsky
2016-06-15 23:12   ` Minchan Kim
2016-06-16  2:48     ` Sergey Senozhatsky
2016-06-16  2:58       ` Minchan Kim
2016-06-16  4:23         ` Sergey Senozhatsky
2016-06-16  4:47           ` Minchan Kim
2016-06-16  5:22             ` Sergey Senozhatsky
2016-06-16  6:47               ` Minchan Kim
2016-06-16  8:42                 ` Sergey Senozhatsky
2016-06-16 10:09                   ` Minchan Kim
2016-06-17  7:28                     ` Joonsoo Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALZtONDQ5yQKV6-jpJGBg7gakV8-7XXmmAATSQq346Tby4WLsg@mail.gmail.com \
    --to=ddstreet@ieee.org \
    --cc=akpm@linux-foundation.org \
    --cc=cmlaika.kim@samsung.com \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git