linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: js1304@gmail.com
To: Andrew Morton <akpm@linux-foundation.org>
Cc: 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: [PATCH 5/9] mm/workingset: use the node counter if memcg is the root memcg
Date: Tue, 11 Feb 2020 15:19:49 +0900	[thread overview]
Message-ID: <1581401993-20041-6-git-send-email-iamjoonsoo.kim@lge.com> (raw)
In-Reply-To: <1581401993-20041-1-git-send-email-iamjoonsoo.kim@lge.com>

From: Joonsoo Kim <iamjoonsoo.kim@lge.com>

In the following patch, workingset detection is implemented for the
swap cache. Swap cache's node is usually allocated by kswapd and it
isn't charged by kmemcg since it is from the kernel thread. So the swap
cache's shadow node is managed by the node list of the list_lru rather
than the memcg specific one.

If counting the shadow node on the root memcg happens to reclaim the slab
object, the shadow node count returns the number of the shadow node on
the node list of the list_lru since root memcg has the kmem_cache_id, -1.

However, the size of pages on the LRU is calculated by using the specific
memcg, so mismatch happens. This causes the number of shadow node not to
be increased to the enough size and, therefore, workingset detection
cannot work correctly. This patch fixes this bug by checking if the memcg
is the root memcg or not. If it is the root memcg, instead of using
the memcg-specific LRU, the system-wide LRU is used to calculate proper
size of the shadow node so that the number of the shadow node can grow
as expected.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
 mm/workingset.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index d04f70a..636aafc 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -468,7 +468,13 @@ static unsigned long count_shadow_nodes(struct shrinker *shrinker,
 	 * PAGE_SIZE / xa_nodes / node_entries * 8 / PAGE_SIZE
 	 */
 #ifdef CONFIG_MEMCG
-	if (sc->memcg) {
+	/*
+	 * Kernel allocation on root memcg isn't regarded as allocation of
+	 * specific memcg. So, if sc->memcg is the root memcg, we need to
+	 * use the count for the node rather than one for the specific
+	 * memcg.
+	 */
+	if (sc->memcg && !mem_cgroup_is_root(sc->memcg)) {
 		struct lruvec *lruvec;
 		int i;
 
-- 
2.7.4



  parent reply	other threads:[~2020-02-11  6:20 UTC|newest]

Thread overview: 17+ 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-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-28  7:42   ` [mm/workingset] 323c95f095: fio.read_bw_MBps 19.5% improvement kernel test robot
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 ` js1304 [this message]
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
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

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=1581401993-20041-6-git-send-email-iamjoonsoo.kim@lge.com \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.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 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).