All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Mel Gorman <mgorman@suse.de>, Hugh Dickins <hughd@google.com>,
	Rafael Aquini <aquini@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Jonathan Corbet <corbet@lwn.net>,
	John Einar Reitan <john.reitan@foss.arm.com>,
	dri-devel@lists.freedesktop.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Gioh Kim <gi-oh.kim@profitbricks.com>
Subject: Re: PATCH v6v2 02/12] mm: migrate: support non-lru movable page migration
Date: Tue, 31 May 2016 09:51:47 +0200	[thread overview]
Message-ID: <bbc87219-d86d-d7a5-2a78-9f09a1549d65@suse.cz> (raw)
In-Reply-To: <20160530162523.GA18314@bbox>

On 05/30/2016 06:25 PM, Minchan Kim wrote:
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -81,6 +81,39 @@ static inline bool migrate_async_suitable(int migratetype)
>>>
>>> #ifdef CONFIG_COMPACTION
>>>
>>> +int PageMovable(struct page *page)
>>> +{
>>> +	struct address_space *mapping;
>>> +
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	if (!__PageMovable(page))
>>> +		return 0;
>>> +
>>> +	mapping = page_mapping(page);
>>> +	if (mapping && mapping->a_ops && mapping->a_ops->isolate_page)
>>> +		return 1;
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL(PageMovable);
>>> +
>>> +void __SetPageMovable(struct page *page, struct address_space *mapping)
>>> +{
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	VM_BUG_ON_PAGE((unsigned long)mapping & PAGE_MAPPING_MOVABLE, page);
>>> +	page->mapping = (void *)((unsigned long)mapping | PAGE_MAPPING_MOVABLE);
>>> +}
>>> +EXPORT_SYMBOL(__SetPageMovable);
>>> +
>>> +void __ClearPageMovable(struct page *page)
>>> +{
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	VM_BUG_ON_PAGE(!PageMovable(page), page);
>>> +	page->mapping = (void *)((unsigned long)page->mapping &
>>> +				PAGE_MAPPING_MOVABLE);
>>> +}
>>> +EXPORT_SYMBOL(__ClearPageMovable);
>>
>> The second confusing thing is that the function is named
>> __ClearPageMovable(), but what it really clears is the mapping
>> pointer,
>> which is not at all the opposite of what __SetPageMovable() does.
>>
>> I know it's explained in the documentation, but it also deserves a
>> comment here so it doesn't confuse everyone who looks at it.
>> Even better would be a less confusing name for the function, but I
>> can't offer one right now.
>
> To me, __ClearPageMovable naming is suitable for user POV.
> It effectively makes the page unmovable. The confusion is just caused
> by the implementation and I don't prefer exported API depends on the
> implementation. So I want to add just comment.
>
> I didn't add comment above the function because I don't want to export
> internal implementation to the user. I think they don't need to know it.
>
> index a7df2ae71f2a..d1d2063b4fd9 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -108,6 +108,11 @@ void __ClearPageMovable(struct page *page)
>  {
>         VM_BUG_ON_PAGE(!PageLocked(page), page);
>         VM_BUG_ON_PAGE(!PageMovable(page), page);
> +       /*
> +        * Clear registered address_space val with keeping PAGE_MAPPING_MOVABLE
> +        * flag so that VM can catch up released page by driver after isolation.
> +        * With it, VM migration doesn't try to put it back.
> +        */
>         page->mapping = (void *)((unsigned long)page->mapping &
>                                 PAGE_MAPPING_MOVABLE);

OK, that's fine!

>>
>>> diff --git a/mm/util.c b/mm/util.c
>>> index 917e0e3d0f8e..b756ee36f7f0 100644
>>> --- a/mm/util.c
>>> +++ b/mm/util.c
>>> @@ -399,10 +399,12 @@ struct address_space *page_mapping(struct page *page)
>>> 	}
>>>
>>> 	mapping = page->mapping;
>>
>> I'd probably use READ_ONCE() here to be safe. Not all callers are
>> under page lock?
>
> I don't understand. Yeah, all caller are not under page lock but at least,
> new user of movable pages should call it under page_lock.
> Yeah, I will write the rule down in document.
> In this case, what kinds of problem do you see?

After more thinking, probably none. It wouldn't prevent any extra races. 
Sorry for the noise.

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Mel Gorman <mgorman@suse.de>, Hugh Dickins <hughd@google.com>,
	Rafael Aquini <aquini@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Jonathan Corbet <corbet@lwn.net>,
	John Einar Reitan <john.reitan@foss.arm.com>,
	dri-devel@lists.freedesktop.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Gioh Kim <gi-oh.kim@profitbricks.com>
Subject: Re: PATCH v6v2 02/12] mm: migrate: support non-lru movable page migration
Date: Tue, 31 May 2016 09:51:47 +0200	[thread overview]
Message-ID: <bbc87219-d86d-d7a5-2a78-9f09a1549d65@suse.cz> (raw)
In-Reply-To: <20160530162523.GA18314@bbox>

On 05/30/2016 06:25 PM, Minchan Kim wrote:
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -81,6 +81,39 @@ static inline bool migrate_async_suitable(int migratetype)
>>>
>>> #ifdef CONFIG_COMPACTION
>>>
>>> +int PageMovable(struct page *page)
>>> +{
>>> +	struct address_space *mapping;
>>> +
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	if (!__PageMovable(page))
>>> +		return 0;
>>> +
>>> +	mapping = page_mapping(page);
>>> +	if (mapping && mapping->a_ops && mapping->a_ops->isolate_page)
>>> +		return 1;
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL(PageMovable);
>>> +
>>> +void __SetPageMovable(struct page *page, struct address_space *mapping)
>>> +{
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	VM_BUG_ON_PAGE((unsigned long)mapping & PAGE_MAPPING_MOVABLE, page);
>>> +	page->mapping = (void *)((unsigned long)mapping | PAGE_MAPPING_MOVABLE);
>>> +}
>>> +EXPORT_SYMBOL(__SetPageMovable);
>>> +
>>> +void __ClearPageMovable(struct page *page)
>>> +{
>>> +	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>> +	VM_BUG_ON_PAGE(!PageMovable(page), page);
>>> +	page->mapping = (void *)((unsigned long)page->mapping &
>>> +				PAGE_MAPPING_MOVABLE);
>>> +}
>>> +EXPORT_SYMBOL(__ClearPageMovable);
>>
>> The second confusing thing is that the function is named
>> __ClearPageMovable(), but what it really clears is the mapping
>> pointer,
>> which is not at all the opposite of what __SetPageMovable() does.
>>
>> I know it's explained in the documentation, but it also deserves a
>> comment here so it doesn't confuse everyone who looks at it.
>> Even better would be a less confusing name for the function, but I
>> can't offer one right now.
>
> To me, __ClearPageMovable naming is suitable for user POV.
> It effectively makes the page unmovable. The confusion is just caused
> by the implementation and I don't prefer exported API depends on the
> implementation. So I want to add just comment.
>
> I didn't add comment above the function because I don't want to export
> internal implementation to the user. I think they don't need to know it.
>
> index a7df2ae71f2a..d1d2063b4fd9 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -108,6 +108,11 @@ void __ClearPageMovable(struct page *page)
>  {
>         VM_BUG_ON_PAGE(!PageLocked(page), page);
>         VM_BUG_ON_PAGE(!PageMovable(page), page);
> +       /*
> +        * Clear registered address_space val with keeping PAGE_MAPPING_MOVABLE
> +        * flag so that VM can catch up released page by driver after isolation.
> +        * With it, VM migration doesn't try to put it back.
> +        */
>         page->mapping = (void *)((unsigned long)page->mapping &
>                                 PAGE_MAPPING_MOVABLE);

OK, that's fine!

>>
>>> diff --git a/mm/util.c b/mm/util.c
>>> index 917e0e3d0f8e..b756ee36f7f0 100644
>>> --- a/mm/util.c
>>> +++ b/mm/util.c
>>> @@ -399,10 +399,12 @@ struct address_space *page_mapping(struct page *page)
>>> 	}
>>>
>>> 	mapping = page->mapping;
>>
>> I'd probably use READ_ONCE() here to be safe. Not all callers are
>> under page lock?
>
> I don't understand. Yeah, all caller are not under page lock but at least,
> new user of movable pages should call it under page_lock.
> Yeah, I will write the rule down in document.
> In this case, what kinds of problem do you see?

After more thinking, probably none. It wouldn't prevent any extra races. 
Sorry for the noise.

--
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>

  parent reply	other threads:[~2016-05-31  7:51 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20 14:23 [PATCH v6 00/12] Support non-lru page migration Minchan Kim
2016-05-20 14:23 ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 01/12] mm: use put_page to free page instead of putback_lru_page Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 02/12] mm: migrate: support non-lru movable page migration Minchan Kim
2016-05-20 14:23 ` Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-27 14:26   ` Vlastimil Babka
2016-05-27 14:26     ` Vlastimil Babka
2016-05-27 14:26     ` Vlastimil Babka
2016-05-30  1:33     ` Minchan Kim
2016-05-30  1:33       ` Minchan Kim
2016-05-30  1:33       ` Minchan Kim
2016-05-30  9:01       ` Vlastimil Babka
2016-05-30  9:01         ` Vlastimil Babka
2016-05-30  9:01         ` Vlastimil Babka
2016-05-30  1:33     ` Minchan Kim
2016-05-27 14:26   ` Vlastimil Babka
2016-05-30  1:39   ` PATCH v6v2 " Minchan Kim
2016-05-30  1:39     ` Minchan Kim
2016-05-30  1:39     ` Minchan Kim
2016-05-30  1:39     ` Minchan Kim
2016-05-30  9:36     ` Vlastimil Babka
2016-05-30  9:36     ` Vlastimil Babka
2016-05-30  9:36       ` Vlastimil Babka
2016-05-30 16:25       ` Minchan Kim
2016-05-30 16:25         ` Minchan Kim
2016-05-30 16:25         ` Minchan Kim
2016-05-31  7:51         ` Vlastimil Babka
2016-05-31  7:51         ` Vlastimil Babka [this message]
2016-05-31  7:51           ` Vlastimil Babka
2016-05-31  0:01     ` [PATCH v6v3 " Minchan Kim
2016-05-31  0:01     ` Minchan Kim
2016-05-31  0:01       ` Minchan Kim
2016-05-31  0:01       ` Minchan Kim
2016-05-31  7:52       ` Vlastimil Babka
2016-05-31  7:52         ` Vlastimil Babka
2016-05-31 23:05         ` Minchan Kim
2016-05-31 23:05           ` Minchan Kim
2016-05-31 23:05         ` Minchan Kim
2016-05-31  7:52       ` Vlastimil Babka
2016-06-13  9:38       ` Anshuman Khandual
2016-06-13  9:38         ` Anshuman Khandual
2016-06-15  2:32         ` Minchan Kim
2016-06-15  2:32           ` Minchan Kim
2016-06-15  6:45           ` Anshuman Khandual
2016-06-15  6:45             ` Anshuman Khandual
2016-06-15  6:45             ` Anshuman Khandual
2016-06-16  0:26             ` Minchan Kim
2016-06-16  0:26             ` Minchan Kim
2016-06-16  0:26               ` Minchan Kim
2016-06-16  0:26               ` Minchan Kim
2016-06-16  3:42               ` Anshuman Khandual
2016-06-16  3:42                 ` Anshuman Khandual
2016-06-16  3:42                 ` Anshuman Khandual
2016-06-16  5:37                 ` Minchan Kim
2016-06-16  5:37                   ` Minchan Kim
2016-06-27  5:51                   ` Anshuman Khandual
2016-06-27  5:51                   ` Anshuman Khandual
2016-06-27  5:51                     ` Anshuman Khandual
2016-06-28  6:39                     ` Minchan Kim
2016-06-28  6:39                     ` Minchan Kim
2016-06-28  6:39                       ` Minchan Kim
2016-06-30  5:56                       ` Anshuman Khandual
2016-06-30  5:56                         ` Anshuman Khandual
2016-06-30  6:18                         ` Minchan Kim
2016-06-30  6:18                         ` Minchan Kim
2016-06-30  6:18                           ` Minchan Kim
2016-06-30  6:18                           ` Minchan Kim
2016-06-30  5:56                       ` Anshuman Khandual
2016-06-16  5:37                 ` Minchan Kim
2016-06-15  2:32         ` Minchan Kim
2016-06-13  9:38       ` Anshuman Khandual
2016-05-20 14:23 ` [PATCH v6 03/12] mm: balloon: use general non-lru movable page feature Minchan Kim
2016-05-20 14:23 ` Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-30 12:16   ` Vlastimil Babka
2016-05-30 12:16   ` Vlastimil Babka
2016-05-30 12:16     ` Vlastimil Babka
2016-05-20 14:23 ` [PATCH v6 04/12] zsmalloc: keep max_object in size_class Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 05/12] zsmalloc: use bit_spin_lock Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 06/12] zsmalloc: use accessor Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 07/12] zsmalloc: factor page chain functionality out Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 08/12] zsmalloc: introduce zspage structure Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 09/12] zsmalloc: separate free_zspage from putback_zspage Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 10/12] zsmalloc: use freeobj for index Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 11/12] zsmalloc: page migration support Minchan Kim
2016-05-20 14:23   ` Minchan Kim
2016-05-24  5:28   ` Sergey Senozhatsky
2016-05-24  5:28     ` Sergey Senozhatsky
2016-05-24  6:28     ` Minchan Kim
2016-05-24  6:28       ` Minchan Kim
2016-05-24  8:05       ` Sergey Senozhatsky
2016-05-24  8:05         ` Sergey Senozhatsky
2016-05-24  8:17         ` Minchan Kim
2016-05-24  8:17           ` Minchan Kim
2016-05-25  5:14       ` Minchan Kim
2016-05-25  5:14         ` Minchan Kim
2016-05-25 15:23         ` Sergey Senozhatsky
2016-05-25 15:23           ` Sergey Senozhatsky
2016-05-26  0:32           ` Minchan Kim
2016-05-26  0:32             ` Minchan Kim
2016-05-26  0:59             ` Sergey Senozhatsky
2016-05-26  0:59               ` Sergey Senozhatsky
2016-05-26  4:37               ` Minchan Kim
2016-05-26  4:37                 ` Minchan Kim
2016-05-26 21:50   ` [PATCH v6r2 " Minchan Kim
2016-05-26 21:50     ` Minchan Kim
2016-05-20 14:23 ` [PATCH v6 12/12] zram: use __GFP_MOVABLE for memory allocation Minchan Kim
2016-05-20 14:23   ` Minchan 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=bbc87219-d86d-d7a5-2a78-9f09a1549d65@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=aquini@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gi-oh.kim@profitbricks.com \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=john.reitan@foss.arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.