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 411BCC76188 for ; Wed, 5 Apr 2023 20:01:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A9576B0071; Wed, 5 Apr 2023 16:01:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7583C6B0074; Wed, 5 Apr 2023 16:01:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F97E6B0075; Wed, 5 Apr 2023 16:01:55 -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 4F52E6B0071 for ; Wed, 5 Apr 2023 16:01:55 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0807A1A0D4B for ; Wed, 5 Apr 2023 20:01:55 +0000 (UTC) X-FDA: 80648408190.18.E7FA33D Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf24.hostedemail.com (Postfix) with ESMTP id 3039B180022 for ; Wed, 5 Apr 2023 20:01:52 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=U19A8LKK; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.174 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680724912; 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: references:dkim-signature; bh=pgGe4pUmwbq6B4NsSylYT8hCeXq6m9SaGK88QHwMshQ=; b=kx0f20LkqH/pr1c2qCRhiQLAtXMq3vlgUUSyM0EYOK2NliRVZOhcNQ93Fs6120qRHd1rKz ns/CYg25hOeDiE6K5lbVFJ/urYrc4wk3HkEXuV1l7HEu7X797ZqDDoP3zJAXupCj2r+BTN HS9DVehGl4x5l5ZJXgjCJBL5DWaEtuc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=U19A8LKK; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.174 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680724912; a=rsa-sha256; cv=none; b=o0sC4wbdyz/YRv/vSEJlC8Ixnn6dEBvFr19JO2pDMkEzqt6XfnFQhZ1iFRGBfYE+NDYcEw 4W4dQ6NCfPjxc921Ji4eo+lVZAlJAFWyC6qSSIvfosIw9f0aWjvQWGGLG35cFVyn83UvIl /jOgAsSwp/JlqYU6AtgU+Nw554lRO30= Received: by mail-qt1-f174.google.com with SMTP id t19so36108583qta.12 for ; Wed, 05 Apr 2023 13:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; t=1680724911; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=pgGe4pUmwbq6B4NsSylYT8hCeXq6m9SaGK88QHwMshQ=; b=U19A8LKKl+fJZGxIKAXOBNvTvfbruhrr9biRcs2jmTzqRJxz4iytcYWdCpajJcxvwL SJ7M89UuRB1y87JneNoNtLAoYdjiP+Y7PTD7ccg6AYHFy0XXhuQgSXJff1QmL5rAj6Dn 5onLrBqZ9ZDU34znBogo1SI+PnwCzyGahtovnaRZjHfKD3c1qB5WyX/s0XdHNuq4G5ny 34qzJcKY+G8YJNQB1ZoQcEUiKw+nY/MFX9Azbkhoi3Ko/K4WTuML2T6c7h0pVu/5T55A E3cKNp0nAcZNcE7onDk+5IJB7MquiTZfDskUcBkVKxPhe7JCHVNa5UErAS3pGWRn/jCW XF6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680724911; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pgGe4pUmwbq6B4NsSylYT8hCeXq6m9SaGK88QHwMshQ=; b=A81DAVFZAWJgjFCdZoIjTKvywVIc845QglVWiEcy0Pl3bc7jOzhN6CSjD/YuxjTScb sR6r6Je6rqtzX1UINYbsL8wIqiT4X38YoBU1rXXtYmDhijifagxDx5ezcClPiSB3u7uO /QAexbmfa1RnPyElbkrW7k8od4THAQ3LO6ylw7xUhIdWYXOH1l8Y7MXa9jfDZi8jUB45 tc9GMmAprpQKtRkg9yzVJfS/ipThGyBpnDfaj+tRkR2MFMgYbepLf3kiALW0HRyQG/HZ 1JMgvhcKzKkueJXYHPMRT7qqUbkY8W8tegutAu5XGIZvGUace6QsLYlcQ/L4uYn7Y2S/ tnDA== X-Gm-Message-State: AAQBX9eTCwHllZx0otVPhGF3LZIw3MaPnrNnevoMrI8Cmey12PUaBNMy fN4aM1EwAj/7TTJfsL6C/LV+Jw== X-Google-Smtp-Source: AKy350aX1Q577kbAVVqqzQ4NQD8iEi6zXbeaKnSWtw5h60ZgijFkV1O+9yZytvy5u9fCAVUX4DekmA== X-Received: by 2002:ac8:5a93:0:b0:3e3:82c4:db44 with SMTP id c19-20020ac85a93000000b003e382c4db44mr6147901qtc.52.1680724911154; Wed, 05 Apr 2023 13:01:51 -0700 (PDT) Received: from localhost (2603-7000-0c01-2716-8f57-5681-ccd3-4a2e.res6.spectrum.com. [2603:7000:c01:2716:8f57:5681:ccd3:4a2e]) by smtp.gmail.com with ESMTPSA id f8-20020a05620a280800b00749fa9e12e9sm4669594qkp.124.2023.04.05.13.01.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Apr 2023 13:01:50 -0700 (PDT) Date: Wed, 5 Apr 2023 16:01:50 -0400 From: Johannes Weiner To: Yu Zhao Cc: Yosry Ahmed , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: global_reclaim() and code documentation (was: Re: [PATCH v3 3/3] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim Message-ID: <20230405200150.GA35884@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3039B180022 X-Rspam-User: X-Stat-Signature: mikkp1sotf41r14b71fn3nkyqbf4gb9w X-HE-Tag: 1680724912-917529 X-HE-Meta: U2FsdGVkX1+uEW/bd9fzZeSKE3n2YVgTa9gcF8rGCGR+Km7/dF0rhrsSfwTAL/bgLvkm95vWkxzrekvHvECe+R/VDrHgylnFdf3sOV/PAPElpNWKadg2fgHyH3+SemlvmgqRE/nERKh6p+5RFG4E5mVCdnneDa0j/o3M8J6Oh5eyyewrovNw1Zmm7nem6tYWG3v7vbxKQVPG7xK1fUFCCQqAQIfcNv46yhrcCu3jrhCvARgxxZpwkP5VL796hxz0QaS0a6ERWcLc2nwXmjNN8vlCs6cVsIG6z5/yuvZaBRviYIxy5ln9ymCXSzPbXAvaRKvZfcr8O8VVd19JaX9DJuUSXPelD4nyhCE5Y3pJt8L+4NlIqksd/ixJUQraN557k+30gN6a+f1910d0oTwUYSzqZAPV6DdBC3R4Duv1Ps2gLkkRuCI4gbzcJHkMBySomHw6qdJuOaCslU/JSlx7UGNrAoeuYASUZXKCx14rrtBHePFW7hW+hC2dDqHICkZ10JwV4IU+DX0JMp3WGIaQdDcZJD09WYNGAX+xiCY3Rsnq8lp4pXYscRBJS9dr2npKaQkyXGE7GnUJE6I9cvxbvOR+1w9VM0+SdJOQwIRHeT2+nWYS65oS2b+CKmO5tPtZKKUrwTAEBn9TC8CUhYUDhcKyydPXnAloiUobuPlkGClwKSohREv+gUnNxd8MMgxy+lFjXig5u6qqkuIbrqysVpuuamWQpqmr6BvSs7CLfKL/r5O4Q4f2zTrk+kuOa483ECK8CtqnhEzmC1lP35lWyPrj59AgUE0xTO40bTl23MsJTgyeg/hBhbhp+W2lE3/aH2gR9GE1I/APgQh94TqxazKynQIVPoHa3EHfKxGbk4zKl+yMDTJDR2JbZ3InfK0UoQI/L194QmVO85HEmGqdo+UBnv3fWRFhIU0wxXEVnd9P01uC9/v+twcG3p/YlQoLliMAyu4Oe3iROB904+w qoCg0Xen 5W+lJnmcY5yh4SEh9M5bE9sQBzbGC/rsd6Ba4DP8Pkfy0PKO5qotKK9Zur7cGOTUEt3bFE2YfhSVGs/GEFDQJNXGbCExklRgC87QMcTWvGH641OepEwvwBWLQRJEe5B+QTqGvp4AxaKJa+tLBqw+1tYroTsw8XwPpCwsI6uwAscd2CYRhH/D4z4ImHGxrHTyzsw8JqJm6UMkqGYQDoQz3CnotiWFvmwm8yczi+sFOGGdEgL48o6fswYq9UPb2BVg67AV2MbTm7KMvbBNhpjc2jnG6bD1LvEcx/KYO9Oqy+j0EKdrLT2IIG135dcpdjhj/iYEu4m0xz0X9W8OEC6SGMjn7++t8F6CvMktESVqxgrR6Mar0nxDkE88CyF4FhfBv7zNsnkvro0wyIOo2osxbyfyahVteVNSH2EEBzeDz42k/9XN2PqnrxhIHOixR9kII5F6SgqNvh8A2PKaBeHpZo62VGLq8vb98lwDuwL0zB6QqS3nOWlI/rPOsvEqDFdDo0eyFsJqpwd3w74nnirZ3wGf0CYqVLRCrjb2l 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:30:11AM -0700, Yosry Ahmed wrote: > On Fri, Mar 31, 2023 at 12:25 AM Yu Zhao wrote: > > On Fri, Mar 31, 2023 at 1:08 AM 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 whether 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 LRUs > > > + * anymore except on highmem systems. > > > + * > > > + * Instead of over-reporting the reclaimed pages in a memcg reclaim, > > > + * 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 significantly > > > + * charged to the memcg under reclaim, and we end up under-reporting, it > > > + * should be fine. The freed pages will be uncharged anyway, even 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 pages 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. I didn't realize it came back, I deleted it a while ago: commit b5ead35e7e1d3434ce436dfcb2af32820ce54589 Author: Johannes Weiner Date: Sat Nov 30 17:55:40 2019 -0800 mm: vmscan: naming fixes: global_reclaim() and sane_reclaim() Seven years after introducing the global_reclaim() function, I still have to double take when reading a callsite. I don't know how others do it, this is a terrible name. Invert the meaning and rename it to cgroup_reclaim(). Could you shed some light on why it was brought back? It's not clear to me from the changelog in a579086c99ed70cc4bfc104348dbe3dd8f2787e6. We also now have this: static bool cgroup_reclaim(struct scan_control *sc) { return sc->target_mem_cgroup; } static bool global_reclaim(struct scan_control *sc) { return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); } The name suggests it's the same thing twice, with opposite polarity. But of course they're subtly different, and not documented. When do you use which?