Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4867862rwl; Tue, 28 Mar 2023 12:29:52 -0700 (PDT) X-Google-Smtp-Source: AKy350akMb8fmNGXYvTMY5XqeZSiHiYmap3JKHS18lwIKBC/M4cSxxXSHOchjQTo4X5B2E2/a44U X-Received: by 2002:a62:6484:0:b0:5aa:4db8:9ab1 with SMTP id y126-20020a626484000000b005aa4db89ab1mr14240154pfb.23.1680031792408; Tue, 28 Mar 2023 12:29:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680031792; cv=none; d=google.com; s=arc-20160816; b=kJM6y3gn0VV5rY0en8j1FzQJxKil6/q9DJ0BYUownDl0gmFuPtiPOiBxQMoTIgGG4J 8Y1to+Y33YqrPZBO3tcIM1xagjEvQR6YREOOIKoA21rI20uSsVmF09Fv2oiQ03pNtJbY IrmSwE/Bo86Hqat6Gw9CVYXtgC3+cPxxMSsCyAk507P3S5Q5nm1bQrQraRw9P3ntcbUN q2oTSYH4fXjfmn0JK+/c69pm6oJmpatyF/PH8ko/KbIzqF+PFKqsi9Ln3uK3DKV8cuTq vAhjJYzU8w97Z66WLm/lyQsZi7dbbq1SDWrBuyryaYfic1mPa6zb6jIVPLtAU3qM+BKN 3BxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=eYVDDjmV6wnF+h+msRo3LvXGWbt+x6xaJ8ueYBE6V3E=; b=vXwEjliIBa6biYSUWGzvMXxcTtSF9mPXlLsOJgFqtySFX9zSF5hc/awOmN4UHLGFpF wYVW3cOw77pc79w9TSO6VKd61niVOO94OtxZkdzgVHjbjKoWlOy7HmAOkrPyMbhJaL0w 2koz9Rhh3ySSDOmC6ITHg2MaYp0wLjn0gen3ZzB3d6W9S6L10bEXoBETTt1bpK/tagJU Co5/vGdWBLa8Pro04ygoPA8LEgbqZL62+qsPVOKGLWOdoIrF91HjtxhTx5FrMHiexR3r 98KUw1+0H7XltpNp5i5TDaceKM1PTxuyUz/xLRemy/7G51JVyF9gvRovQ2n6SgQ58Jm/ Gnhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=BaLdgM8s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h19-20020a631213000000b00502f0ddd50bsi33105372pgl.382.2023.03.28.12.29.38; Tue, 28 Mar 2023 12:29:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=BaLdgM8s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229617AbjC1T0B (ORCPT + 99 others); Tue, 28 Mar 2023 15:26:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjC1TZ7 (ORCPT ); Tue, 28 Mar 2023 15:25:59 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FE0030F1 for ; Tue, 28 Mar 2023 12:25:57 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id er13so13064148edb.9 for ; Tue, 28 Mar 2023 12:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680031555; 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=eYVDDjmV6wnF+h+msRo3LvXGWbt+x6xaJ8ueYBE6V3E=; b=BaLdgM8sqhxXwzLNbWAseZe+RqH1V2Sxs6j8JzObpqe9YjEP8JsX8TXeaMf+tc9bym 4pp1VtiAZrkxoLk2jEtPY08u49gPKMB4A0lOKXg2oLmI0TroEAp1axYyJ3B+ARJsLv+c mw/J0LkPXvTpu0NHSZ4T9irM+kQ2F5RGBgpTu41aaqfuGNoawCk7WRP7VaDojs2eXk+I Cm0w6GcKp0rzsvxN21JQV73VRADwsRLJd6t6qgfy7/KJ2DjGHz6fyMJf4qXPhjfQVBBe H4Xjep3XOfuuMGi+vysHQx0repx2BNbxM986ZzMl8QQEWv1tRFLZUpz6u5NU3aX1h0Co rTuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680031555; 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=eYVDDjmV6wnF+h+msRo3LvXGWbt+x6xaJ8ueYBE6V3E=; b=qYGSrbDOo8v+l0tIynbGb+s4i3UJp41VoJ8exBwI1+K5Y9QDQhKKeCCuzfftGUo49q 8otSatQYNFGEMK5ZevvOLzPG0CrCoo3B/75k07UARgXGiZw+CYjTgiN0RV7hFs8FkrwW JYF67wl0TTlRF9idkULN2RCCCtvNbOLIp09piiVWMoD7w4msFFJVeRYpcKiMfMnCayr5 cESFE71hHED1lGBlgJ+BLLcZkZqTB67vrsnrZdKCeCn2KV4DxHTf7Etls2j4GpetkvTL r7gSWb1+igSN2UOQneiwvqUXeH/TykFcYIzi1trX2t/qb7ZvyZsjuG4KbCaPY/XtDw1g B+OQ== X-Gm-Message-State: AAQBX9e8bA1Ea7XyEPjipT7xKyENk2SNcbJSGvYidtxCa3y6QSvzIFrW SKGXK8nIPeixn6LEpWTsevRrDgSSEl57XV1x+hU4pA== X-Received: by 2002:a50:9f62:0:b0:4fa:d8aa:74ad with SMTP id b89-20020a509f62000000b004fad8aa74admr8151266edf.8.1680031555382; Tue, 28 Mar 2023 12:25:55 -0700 (PDT) MIME-Version: 1.0 References: <20230328061638.203420-1-yosryahmed@google.com> <20230328061638.203420-8-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 28 Mar 2023 12:25:19 -0700 Message-ID: Subject: Re: [PATCH v1 7/9] workingset: memcg: sleep when flushing stats in workingset_refault() To: Shakeel Butt Cc: Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 28, 2023 at 8:18=E2=80=AFAM Shakeel Butt = wrote: > > On Mon, Mar 27, 2023 at 11:16=E2=80=AFPM Yosry Ahmed wrote: > > > > In workingset_refault(), we call mem_cgroup_flush_stats_ratelimited() > > to flush stats within an RCU read section and with sleeping disallowed. > > Move the call to mem_cgroup_flush_stats_ratelimited() above the RCU rea= d > > section and allow sleeping to avoid unnecessarily performing a lot of > > work without sleeping. > > > > Since workingset_refault() is the only caller of > > mem_cgroup_flush_stats_ratelimited(), just make it call the non-atomic > > mem_cgroup_flush_stats(). > > > > Signed-off-by: Yosry Ahmed > > A nit below: > > Acked-by: Shakeel Butt > > > --- > > mm/memcontrol.c | 12 ++++++------ > > mm/workingset.c | 4 ++-- > > 2 files changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 57e8cbf701f3..0c0e74188e90 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -674,12 +674,6 @@ void mem_cgroup_flush_stats_atomic(void) > > __mem_cgroup_flush_stats_atomic(); > > } > > > > -void mem_cgroup_flush_stats_ratelimited(void) > > -{ > > - if (time_after64(jiffies_64, READ_ONCE(flush_next_time))) > > - mem_cgroup_flush_stats_atomic(); > > -} > > - > > /* non-atomic functions, only safe from sleepable contexts */ > > static void __mem_cgroup_flush_stats(void) > > { > > @@ -695,6 +689,12 @@ void mem_cgroup_flush_stats(void) > > __mem_cgroup_flush_stats(); > > } > > > > +void mem_cgroup_flush_stats_ratelimited(void) > > +{ > > + if (time_after64(jiffies_64, READ_ONCE(flush_next_time))) > > + mem_cgroup_flush_stats(); > > +} > > + > > static void flush_memcg_stats_dwork(struct work_struct *w) > > { > > __mem_cgroup_flush_stats(); > > diff --git a/mm/workingset.c b/mm/workingset.c > > index af862c6738c3..7d7ecc46521c 100644 > > --- a/mm/workingset.c > > +++ b/mm/workingset.c > > @@ -406,6 +406,8 @@ void workingset_refault(struct folio *folio, void *= shadow) > > unpack_shadow(shadow, &memcgid, &pgdat, &eviction, &workingset)= ; > > eviction <<=3D bucket_order; > > > > + /* Flush stats (and potentially sleep) before holding RCU read = lock */ > > I think the only reason we use rcu lock is due to > mem_cgroup_from_id(). Maybe we should add mem_cgroup_tryget_from_id(). > The other caller of mem_cgroup_from_id() in vmscan is already doing > the same and could use mem_cgroup_tryget_from_id(). I think different callers of mem_cgroup_from_id() want different things. (a) workingset_refault() reads the memcg from the id and doesn't really care if the memcg is online or not. (b) __mem_cgroup_uncharge_swap() reads the memcg from the id and drops refs acquired on the swapout path. It doesn't need tryget as we should know for a fact that we are holding refs from the swapout path. It doesn't care if the memcg is online or not. (c) mem_cgroup_swapin_charge_folio() reads the memcg from the id and then gets a ref with css_tryget_online() -- so only if the refcount is non-zero and the memcg is online. So we would at least need mem_cgroup_tryget_from_id() and mem_cgroup_tryget_online_from_id() to eliminate all direct calls of mem_cgroup_from_id(). I am hesitant about (b) because if we use mem_cgroup_tryget_from_id() the code will be getting a ref, then dropping the ref we have been carrying from swapout, then dropping the ref we just acquired. WDYT? > > Though this can be done separately to this series (if we decide to do > it at all).