linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Yu Zhao <yuzhao@google.com>
Cc: linux-mm@kvack.org,  Alex Shi <alex.shi@linux.alibaba.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	 Hillf Danton <hdanton@sina.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	 Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Matthew Wilcox <willy@infradead.org>,
	 Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@suse.com>,
	 Roman Gushchin <guro@fb.com>,  Vlastimil Babka <vbabka@suse.cz>,
	 Wei Yang <richard.weiyang@linux.alibaba.com>,
	Yang Shi <shy828301@gmail.com>,
	 linux-kernel@vger.kernel.org, page-reclaim@google.com
Subject: Re: [PATCH v1 10/14] mm: multigenerational lru: core
Date: Tue, 16 Mar 2021 10:08:51 +0800	[thread overview]
Message-ID: <87im5rsvd8.fsf@yhuang6-desk1.ccr.corp.intel.com> (raw)

Yu Zhao <yuzhao@google.com> writes:
[snip]

> +/* Main function used by foreground, background and user-triggered aging. */
> +static bool walk_mm_list(struct lruvec *lruvec, unsigned long next_seq,
> +			 struct scan_control *sc, int swappiness)
> +{
> +	bool last;
> +	struct mm_struct *mm = NULL;
> +	int nid = lruvec_pgdat(lruvec)->node_id;
> +	struct mem_cgroup *memcg = lruvec_memcg(lruvec);
> +	struct lru_gen_mm_list *mm_list = get_mm_list(memcg);
> +
> +	VM_BUG_ON(next_seq > READ_ONCE(lruvec->evictable.max_seq));
> +
> +	/*
> +	 * For each walk of the mm list of a memcg, we decrement the priority
> +	 * of its lruvec. For each walk of memcgs in kswapd, we increment the
> +	 * priorities of all lruvecs.
> +	 *
> +	 * So if this lruvec has a higher priority (smaller value), it means
> +	 * other concurrent reclaimers (global or memcg reclaim) have walked
> +	 * its mm list. Skip it for this priority to balance the pressure on
> +	 * all memcgs.
> +	 */
> +#ifdef CONFIG_MEMCG
> +	if (!mem_cgroup_disabled() && !cgroup_reclaim(sc) &&
> +	    sc->priority > atomic_read(&lruvec->evictable.priority))
> +		return false;
> +#endif
> +
> +	do {
> +		last = get_next_mm(lruvec, next_seq, swappiness, &mm);
> +		if (mm)
> +			walk_mm(lruvec, mm, swappiness);
> +
> +		cond_resched();
> +	} while (mm);

It appears that we need to scan the whole address space of multiple
processes in this loop?

If so, I have some concerns about the duration of the function.  Do you
have some number of the distribution of the duration of the function?
And may be the number of mm_struct and the number of pages scanned.

In comparison, in the traditional LRU algorithm, for each round, only a
small subset of the whole physical memory is scanned.

Best Regards,
Huang, Ying

> +
> +	if (!last) {
> +		/* foreground aging prefers not to wait unless "necessary" */
> +		if (!current_is_kswapd() && sc->priority < DEF_PRIORITY - 2)
> +			wait_event_killable(mm_list->nodes[nid].wait,
> +				next_seq < READ_ONCE(lruvec->evictable.max_seq));
> +
> +		return next_seq < READ_ONCE(lruvec->evictable.max_seq);
> +	}
> +
> +	VM_BUG_ON(next_seq != READ_ONCE(lruvec->evictable.max_seq));
> +
> +	inc_max_seq(lruvec);
> +
> +#ifdef CONFIG_MEMCG
> +	if (!mem_cgroup_disabled())
> +		atomic_add_unless(&lruvec->evictable.priority, -1, 0);
> +#endif
> +
> +	/* order against inc_max_seq() */
> +	smp_mb();
> +	/* either we see any waiters or they will see updated max_seq */
> +	if (waitqueue_active(&mm_list->nodes[nid].wait))
> +		wake_up_all(&mm_list->nodes[nid].wait);
> +
> +	wakeup_flusher_threads(WB_REASON_VMSCAN);
> +
> +	return true;
> +}
> +

[snip]

Best Regards,
Huang, Ying


             reply	other threads:[~2021-03-16  2:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16  2:08 Huang, Ying [this message]
2021-03-16  4:45 ` [PATCH v1 10/14] mm: multigenerational lru: core Yu Zhao
2021-03-16  6:52   ` Huang, Ying
2021-03-16  8:24     ` Yu Zhao
2021-03-16  8:53       ` Huang, Ying
2021-03-16 18:40         ` Yu Zhao
  -- strict thread matches above, loose matches on Subject: below --
2021-03-13  7:57 [PATCH v1 00/14] Multigenerational LRU Yu Zhao
2021-03-13  7:57 ` [PATCH v1 10/14] mm: multigenerational lru: core Yu Zhao
2021-03-15  2:02   ` Andi Kleen
2021-03-15  3:37     ` Yu Zhao

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=87im5rsvd8.fsf@yhuang6-desk1.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hdanton@sina.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=page-reclaim@google.com \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=shy828301@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).