All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: js1304@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>, Hugh Dickins <hughd@google.com>,
	Minchan Kim <minchan@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Mel Gorman <mgorman@techsingularity.net>,
	kernel-team@lge.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 9/9] mm/swap: count a new anonymous page as a reclaim_state's rotate
Date: Wed, 12 Feb 2020 11:35:34 +0800	[thread overview]
Message-ID: <20200212033534.3744-1-hdanton@sina.com> (raw)
In-Reply-To: <1581401993-20041-1-git-send-email-iamjoonsoo.kim@lge.com>


On Mon, 10 Feb 2020 22:20:37 -0800 (PST)
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> 
> reclaim_stat's rotate is used for controlling the ratio of scanning page
> between file and anonymous LRU. All new anonymous pages are counted
> for rotate before the patch, protecting anonymous pages on active LRU, and,
> it makes that reclaim on anonymous LRU is less happened than file LRU.
> 
> Now, situation is changed. all new anonymous pages are not added
> to the active LRU so rotate would be far less than before. It will cause
> that reclaim on anonymous LRU happens more and it would result in bad
> effect on some system that is optimized for previous setting.
> 
> Therefore, this patch counts a new anonymous page as a reclaim_state's
> rotate. Although it is non-logical to add this count to
> the reclaim_state's rotate in current algorithm, reducing the regression
> would be more important.
> 
> I found this regression on kernel-build test and it is roughly 2~5%
> performance degradation. With this workaround, performance is completely
> restored.
> 
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> ---
>  mm/swap.c | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/swap.c b/mm/swap.c
> index 18b2735..c3584af 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -187,6 +187,9 @@ int get_kernel_page(unsigned long start, int write, struct page **pages)
>  }
>  EXPORT_SYMBOL_GPL(get_kernel_page);
>  
> +static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
> +				 void *arg);
> +
>  static void pagevec_lru_move_fn(struct pagevec *pvec,
>  	void (*move_fn)(struct page *page, struct lruvec *lruvec, void *arg),
>  	void *arg)
> @@ -207,6 +210,19 @@ static void pagevec_lru_move_fn(struct pagevec *pvec,
>  			spin_lock_irqsave(&pgdat->lru_lock, flags);
>  		}
>  
> +		if (move_fn == __pagevec_lru_add_fn) {
> +			struct list_head *entry = &page->lru;
> +			unsigned long next = (unsigned long)entry->next;
> +			unsigned long rotate = next & 2;
> +
> +			if (rotate) {
> +				VM_BUG_ON(arg);
> +
> +				next = next & ~2;
> +				entry->next = (struct list_head *)next;
> +				arg = (void *)rotate;
> +			}
> +		}
>  		lruvec = mem_cgroup_page_lruvec(page, pgdat);
>  		(*move_fn)(page, lruvec, arg);
>  	}
> @@ -475,6 +491,14 @@ void lru_cache_add_inactive_or_unevictable(struct page *page,
>  				    hpage_nr_pages(page));
>  		count_vm_event(UNEVICTABLE_PGMLOCKED);
>  	}
> +
> +	if (PageSwapBacked(page) && evictable) {
> +		struct list_head *entry = &page->lru;
> +		unsigned long next = (unsigned long)entry->next;
> +
> +		next = next | 2;
> +		entry->next = (struct list_head *)next;
> +	}
>  	lru_cache_add(page);
>  }
>  
> @@ -927,6 +951,7 @@ static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
>  {
>  	enum lru_list lru;
>  	int was_unevictable = TestClearPageUnevictable(page);
> +	unsigned long rotate = (unsigned long)arg;
>  
>  	VM_BUG_ON_PAGE(PageLRU(page), page);
>  
> @@ -962,7 +987,7 @@ static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
>  	if (page_evictable(page)) {
>  		lru = page_lru(page);
>  		update_page_reclaim_stat(lruvec, page_is_file_cache(page),
> -					 PageActive(page));
> +					 PageActive(page) | rotate);


Is it likely to rotate a page if we know it's not active?

 		update_page_reclaim_stat(lruvec, page_is_file_cache(page),
-					 PageActive(page));
+					 PageActive(page) ||
+					 !page_is_file_cache(page));


>  		if (was_unevictable)
>  			count_vm_event(UNEVICTABLE_PGRESCUED);
>  	} else {
> -- 
> 2.7.4



  parent reply	other threads:[~2020-02-12  3:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11  6:19 [PATCH 0/9] workingset protection/detection on the anonymous LRU list js1304
2020-02-11  6:19 ` [PATCH 1/9] mm/vmscan: make active/inactive ratio as 1:1 for anon lru js1304
2020-02-27  2:29   ` [mm/vmscan] dcf33bfdfb: vm-scalability.median 402.4% improvement kernel test robot
2020-02-27  2:29     ` kernel test robot
2020-02-11  6:19 ` [PATCH 2/9] mm/vmscan: protect the workingset on anonymous LRU js1304
2020-02-11  6:19 ` [PATCH 3/9] mm/workingset: extend the workingset detection for anon LRU js1304
2020-02-14  4:07   ` Joonsoo Kim
2020-02-14  4:07     ` Joonsoo Kim
2020-02-28  7:42   ` [mm/workingset] 323c95f095: fio.read_bw_MBps 19.5% improvement kernel test robot
2020-02-28  7:42     ` kernel test robot
2020-02-28 10:03     ` Joonsoo Kim
2020-02-28 10:03       ` Joonsoo Kim
2020-02-28 10:03       ` Joonsoo Kim
2020-02-11  6:19 ` [PATCH 4/9] mm/swapcache: support to handle the value in swapcache js1304
2020-02-11  6:19 ` [PATCH 5/9] mm/workingset: use the node counter if memcg is the root memcg js1304
2020-02-11  6:19 ` [PATCH 6/9] mm/workingset: handle the page without memcg js1304
2020-02-11  6:19 ` [PATCH 7/9] mm/swap: implement workingset detection for anonymous LRU js1304
2020-02-11  6:19 ` [PATCH 8/9] mm/vmscan: restore active/inactive ratio " js1304
2020-02-11  6:19 ` [PATCH 9/9] mm/swap: count a new anonymous page as a reclaim_state's rotate js1304
2020-02-12  3:35 ` Hillf Danton [this message]
2020-02-12 11:00   ` Joonsoo Kim
2020-02-12 11:00     ` Joonsoo Kim
2020-02-14  4:12 ` [PATCH 0/9] workingset protection/detection on the anonymous LRU list Joonsoo Kim
2020-02-14  4:12   ` 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=20200212033534.3744-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    /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.