linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 "Darrick J. Wong" <djwong@kernel.org>,
	Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	 Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	 "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	 David Hildenbrand <david@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Peter Xu <peterx@redhat.com>,  NeilBrown <neilb@suse.de>,
	Shakeel Butt <shakeelb@google.com>,
	Michal Hocko <mhocko@kernel.org>,  Yu Zhao <yuzhao@google.com>,
	Dave Chinner <david@fromorbit.com>,
	 Tim Chen <tim.c.chen@linux.intel.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-xfs@vger.kernel.org, linux-mm@kvack.org,
	 Yosry Ahmed <yosryahmed@google.com>
Subject: [PATCH v6 0/3] Ignore non-LRU-based reclaim in memcg reclaim
Date: Thu, 13 Apr 2023 10:40:31 +0000	[thread overview]
Message-ID: <20230413104034.1086717-1-yosryahmed@google.com> (raw)

Upon running some proactive reclaim tests using memory.reclaim, we
noticed some tests flaking where writing to memory.reclaim would be
successful even though we did not reclaim the requested amount fully
Looking further into it, I discovered that *sometimes* we overestimate
the number of reclaimed pages in memcg reclaim.

Reclaimed pages through other means than LRU-based reclaim are tracked
through reclaim_state in struct scan_control, which is stashed in
current task_struct. These pages are added to the number of reclaimed
pages through LRUs. For memcg reclaim, these pages generally cannot be
linked to the memcg under reclaim and can cause an overestimated count
of reclaimed pages. This short series tries to address that.

Patch 1 ignores pages reclaimed outside of LRU reclaim in memcg reclaim.
The pages are uncharged anyway, so even if we end up under-reporting
reclaimed pages we will still succeed in making progress during
charging.

Patches 2-3 are just refactoring. Patch 2 moves set_reclaim_state()
helper next to flush_reclaim_state(). Patch 3 adds a helper that wraps
updating current->reclaim_state, and renames
reclaim_state->reclaimed_slab to reclaim_state->reclaimed.

v5 -> v6:
- Re-arranged the patches:
  - Pulled flush_reclaim_state() helper with the clarifyng comment to
    the first patch so that the patch is clear on its own (David
    Hildenbrand).
  - Separated moving set_reclaim_state() to a separate patch so that we
    can easily drop it if deemed unnecessary (Questioned by Peter Xu).
- Added a fixes tag (David Hildenbrand).
- Reworded comment in flush_reclaim_state() (David Hildenbrand and Tim
  Chen).
- Dropped reclaim_state argument to flush_reclaim_state() and use
  current->reclaim_state directly instead (Peter Xu).

v5: https://lore.kernel.org/linux-mm/20230405185427.1246289-1-yosryahmed@google.com/

Yosry Ahmed (3):
  mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim
  mm: vmscan: move set_task_reclaim_state() near flush_reclaim_state()
  mm: vmscan: refactor updating current->reclaim_state

 fs/inode.c           |  3 +-
 fs/xfs/xfs_buf.c     |  3 +-
 include/linux/swap.h | 17 ++++++++++-
 mm/slab.c            |  3 +-
 mm/slob.c            |  6 ++--
 mm/slub.c            |  5 ++-
 mm/vmscan.c          | 72 ++++++++++++++++++++++++++++++++------------
 7 files changed, 76 insertions(+), 33 deletions(-)

-- 
2.40.0.577.gac1e443424-goog



             reply	other threads:[~2023-04-13 10:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 10:40 Yosry Ahmed [this message]
2023-04-13 10:40 ` [PATCH v6 1/3] mm: vmscan: ignore " Yosry Ahmed
2023-04-13 10:45   ` Yosry Ahmed
2023-04-13 11:16   ` David Hildenbrand
2023-04-13 11:25     ` Yosry Ahmed
2023-04-14  8:15   ` Michal Hocko
2023-05-01 10:12   ` Yosry Ahmed
2023-04-13 10:40 ` [PATCH v6 2/3] mm: vmscan: move set_task_reclaim_state() near flush_reclaim_state() Yosry Ahmed
2023-04-13 11:19   ` David Hildenbrand
2023-04-13 11:26     ` Yosry Ahmed
2023-04-14  8:16   ` Michal Hocko
2023-04-13 10:40 ` [PATCH v6 3/3] mm: vmscan: refactor updating current->reclaim_state Yosry Ahmed
2023-04-13 11:20   ` David Hildenbrand
2023-04-13 11:29     ` Yosry Ahmed
2023-04-13 11:31       ` David Hildenbrand
2023-04-13 21:00       ` Dave Chinner
2023-04-13 21:38         ` Yosry Ahmed
2023-04-14 21:47           ` Andrew Morton
2023-04-14 23:11             ` Yosry Ahmed
2023-04-14  8:18   ` Michal Hocko

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=20230413104034.1086717-1-yosryahmed@google.com \
    --to=yosryahmed@google.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=neilb@suse.de \
    --cc=peterx@redhat.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --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