From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7748C6FD18 for ; Fri, 31 Mar 2023 07:30:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BE146B0071; Fri, 31 Mar 2023 03:30:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 547206B0072; Fri, 31 Mar 2023 03:30:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C1A86B0074; Fri, 31 Mar 2023 03:30:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 26E4D6B0071 for ; Fri, 31 Mar 2023 03:30:51 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 018494036D for ; Fri, 31 Mar 2023 07:30:50 +0000 (UTC) X-FDA: 80628371502.13.17576D0 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf24.hostedemail.com (Postfix) with ESMTP id 1FC81180008 for ; Fri, 31 Mar 2023 07:30:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZJ2LTdKf; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680247849; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H3XUuqj7bKq4sqEKBJ9kOUJxwFH8O9yCA3hlxqudGM0=; b=6zUzxPD05iIkVkpB5PCEXPZao9q2rpmd5WnqAo7i7iOPca+MvCa3iAifsbouEVSwnT6gvE OIbKoUt5lCDtKKA1/pCLo+cu3MvCD4bT09xwBLcmVadgBB0TSfQW0ntd1K1KzKDPoX+Lvl /93V4OGI1IcaXnIw6RhBZLsNlSU8KZw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZJ2LTdKf; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680247849; a=rsa-sha256; cv=none; b=59XXD2u4ZjxSvOiwy82CGysBN4+X9k8VR8Rb/FSrFz7SbfYpZzTOiAryvZOWNdNnuImOfs dvaM/sfYsUGZ3jEXniXKq9v00ky4L+HMPpxczlDdzAxDgiOuWCT7rbcB6OU7XpQDdVcB/k tR6jBTnESC229QSQTAyyoCa4zAqYw5w= Received: by mail-ed1-f52.google.com with SMTP id x3so86058714edb.10 for ; Fri, 31 Mar 2023 00:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680247847; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H3XUuqj7bKq4sqEKBJ9kOUJxwFH8O9yCA3hlxqudGM0=; b=ZJ2LTdKfP/dAFMQDQkpdCGFmdqEJnIPuRIEmPgNneqWjwxu56d8a9f1xM1kEqG53C8 hKtc3aFtSKmXBq7xMndGMx9yInLTGifW7IFhF+y/nsdiPAkwH79Li1rdyvUunm6K+kIF fuVosgq7RsPqtx+KDgnV80nxZckDEMDTGGRehphSIv5SOMiHFn2+nN88e7YhKNn6UXdK xPl8SyLKrQhrDzWqFEQGW9Ur+LD8P6Jp6MeBDz1jTUBit3TtXxKXj4TJ979fGqTnuVqU JwW2zuI12L5XMn6L0d0gI36rkXhJta0wkNZJYbuuOfOSlx6z0tfhlogJEK6abpUX34lg QtUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680247847; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H3XUuqj7bKq4sqEKBJ9kOUJxwFH8O9yCA3hlxqudGM0=; b=zvGaZoBGqIf9c/+fcgg+m+Vj3k4cc/JoMeqq4iUbAqxUM4dgI1bpEWhFH3/w0O1YVB 1OtN3YLjlH+yp70FNX+IWu0gm9F+SIUx33FEVO+HUxJgtHS7LFxCdawdzSBFuvuIUS/D vDanLZ04t2PpNtXGoYyUiYyK6TfySdsg9Djwjb0PHQ37CtalvTw3QxT2Rs3BUdT4Rc8W /LP5lPzAXI9S1NqyYqsMl0KJfsPWfs7uFB/O0bVf2DlhDuhYGQAXB3pJu9VFwd7Y0zBB 6Mza7sVt8ele0mFWvGpbcGuYAdbQSIWKA72i42PY5jAlWlybRekZQLsAztVtQHlbR0GF zt9g== X-Gm-Message-State: AAQBX9eFV/R/dPqNrjz+4Vq/d0w1oQ6nwRFAITbWPqgQzCVLR/ay4yOj hcufQunXyPSmRDFevinleItXAz5JOASsuL3+MENpyA== X-Google-Smtp-Source: AKy350b5AcmwLZ9juLlS9K/F62ATFOsAhPvyQLkDd1WrL6qYD19g5H8RANCYexuuLD3iuFmBRlqQISUwO5ZWA2jECMo= X-Received: by 2002:a17:906:2a15:b0:933:7658:8b44 with SMTP id j21-20020a1709062a1500b0093376588b44mr11617095eje.15.1680247847390; Fri, 31 Mar 2023 00:30:47 -0700 (PDT) MIME-Version: 1.0 References: <20230331070818.2792558-1-yosryahmed@google.com> <20230331070818.2792558-4-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 31 Mar 2023 00:30:11 -0700 Message-ID: Subject: Re: [PATCH v3 3/3] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim To: Yu Zhao Cc: Andrew Morton , Alexander Viro , "Darrick J. Wong" , Christoph Lameter , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Matthew Wilcox (Oracle)" , Miaohe Lin , David Hildenbrand , Johannes Weiner , Peter Xu , NeilBrown , Shakeel Butt , Michal Hocko , Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: fsdrfa7trfrzq84koebpo4ta16m1qc6n X-Rspamd-Queue-Id: 1FC81180008 X-HE-Tag: 1680247848-906030 X-HE-Meta: U2FsdGVkX19rA6RyIJCh6DbU1Zs3H2EY3G6ycZNfYICWmLnuGqFJ1EOX71z0Jqp4VCUuDQ6pD3yMWeZk1KnpnFsSzhw/uCp/c7mjbeO1moFA2rHJr3KLuIzqtvmBe+6HsIvPzR5QsSblCJ1nc9+FS0eAO9bMoVcXDtucII8zpO1VRYtTJDbCz0heYPM+hSAKgdox3325ZMjt/gZU2iajXYUtp2gw6VYIJk8+Z1qa+XWLPhX/kLGkAWKYeYQVcC4TblMb3p3mglQakF/mQvNViZPwM1PyBgoLQn/KzuWAc/aBCgmiAlrC5HopNHcTMlMI8rc8BrA2hNvK9soHfJ1Kk8mnhIL7tPu9eC4MmaOyhFvnfOQI2IZff1RWuGklMddwu0cqeExh6OWIcKMk872OHbOq+B23FvkN+0sn9Mx5ybkKrebFoOMSAETPadKvQHcB0DCL1yhL6Q773UyjjdbxdsADxuK3ZzCc6eQLGn49/TPeyUnAdd14JlvwtJrLFwlATZ5YFqOu/f/3ypkxjnw4MGycOkTcABCl3FbJ9v2+K8anW/rrA3bDKvToso/zLLW+EIkcGYqqqXUAm23h95LGp3ZOK3l3vg0DvjjStldfHNkWEDaAIgwTuG4hE8eP+W0ahyR/ZRfsY7N4wzQWtgRKWKkvBqiI6UjKRd4MEzqoMiwLpdsdNw8wJHsiApX39EkFTwkc/QvXoRwWSJfwrF6nCtqq6+ftADTAfo2AJX3VQVZn5zvU8KYIJT1BBHUROXvZghrJThVRDwT8MTr26ZZoOMdAGbijEcFiubOdV56iVHeA9pm9UfmYcxGb/mDLo7ohlFhf6+Xy+afbrKeZdwTRgeNS6YjnSahzXNkDraJox1Ef/2V+1V09Mdn6lyZ8mdURegWy+nfyI0+pn1GVx8QP+rrYB8bVlhsc+4giWEVo0JTVqZYyePytwT2AAtO8Lm++wEkXZR0SFoEPP9a+Cca VAe38dcZ QxHdZ6/UeECVGV1yTZcFwBgqRmAn6ve90qeTW+QbEI2izICVuTeysHUuy781RXS277xt3VNVmD5AXQGZvoXz4mdHwEcQfGLJyOovoSl35u4mMVd2b9odQX7wZCnn4JP2+SCZCZ0WiFxmo6HTMq9XG3ioNd0PaKnW6usEq+g8bFdIwvA0OeCa/9MXGvv3LcPduh5sftLTtxYVPBKZjkyOSut+4F8JulAzlsqdLZY5IO+tQnuMhMYxjO/0MT11/fksYPqvlUl93Icf5cGgO+IsrXpEJnQB4eXpLQHa7oGp2/T+KUO1/fLufnQcKa7sppuHc5u5krDio51kiAOyQcd7qirSYIA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Mar 31, 2023 at 12:25=E2=80=AFAM Yu Zhao wrote: > > On Fri, Mar 31, 2023 at 1:08=E2=80=AFAM Yosry Ahmed wrote: > > ... > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index a3e38851b34ac..bf9d8e175e92a 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -533,7 +533,35 @@ EXPORT_SYMBOL(mm_account_reclaimed_pages); > > static void flush_reclaim_state(struct scan_control *sc, > > struct reclaim_state *rs) > > { > > - if (rs) { > > + /* > > + * Currently, reclaim_state->reclaimed includes three types of = pages > > + * freed outside of vmscan: > > + * (1) Slab pages. > > + * (2) Clean file pages from pruned inodes. > > + * (3) XFS freed buffer pages. > > + * > > + * For all of these cases, we have no way of finding out whethe= r these > > + * pages were related to the memcg under reclaim. For example, = a freed > > + * slab page could have had only a single object charged to the= memcg > > + * under reclaim. Also, populated inodes are not on shrinker LR= Us > > + * anymore except on highmem systems. > > + * > > + * Instead of over-reporting the reclaimed pages in a memcg rec= laim, > > + * only count such pages in system-wide reclaim. This prevents > > + * unnecessary retries during memcg charging and false positive= from > > + * proactive reclaim (memory.reclaim). > > What happens when writing to the root memory.reclaim? > > > + * > > + * For uncommon cases were the freed pages were actually signif= icantly > > + * charged to the memcg under reclaim, and we end up under-repo= rting, it > > + * should be fine. The freed pages will be uncharged anyway, ev= en if > > + * they are not reported properly, and we will be able to make = forward > > + * progress in charging (which is usually in a retry loop). > > + * > > + * We can go one step further, and report the uncharged objcg p= ages in > > + * memcg reclaim, to make reporting more accurate and reduce > > + * under-reporting, but it's probably not worth the complexity = for now. > > + */ > > + if (rs && !cgroup_reclaim(sc)) { > > To answer the question above, global_reclaim() would be preferred. Great point, global_reclaim() is fairly recent. I didn't see it before. Thanks for pointing it out. I will change it for v4 -- will wait for more feedback before respinning. Thanks Yu!