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 19039C76196 for ; Tue, 28 Mar 2023 19:02:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A29BA900002; Tue, 28 Mar 2023 15:02:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D9CD6B0075; Tue, 28 Mar 2023 15:02:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A159900002; Tue, 28 Mar 2023 15:02:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 781316B0074 for ; Tue, 28 Mar 2023 15:02:39 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 51E9AA04C8 for ; Tue, 28 Mar 2023 19:02:39 +0000 (UTC) X-FDA: 80619228438.29.FE2460F Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf25.hostedemail.com (Postfix) with ESMTP id 6CBADA0016 for ; Tue, 28 Mar 2023 19:02:37 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F94AXc7U; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.48 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=1680030157; 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=sg40HJuMXcACzrQyQIiyBgX+jk4GkAV6HLHPK6bGfcI=; b=QMV7GOxrjfYaNFAbi3q3S2SMw0l9UYpXUNS6WYJY1UjwCDSVAEsTr5TrNlE17clqQ/G6gT aMFk8X6J1M9fyeRDO8Zi1TQkcowH1SGLN6pzOp+S4hsDlw1DK6/oWnYVWj2f0chwiw1g4z q4F6rK4yQWF+4sQxkcMiMLbiaknNTfs= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F94AXc7U; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.48 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=1680030157; a=rsa-sha256; cv=none; b=8KLdh/Gb8aKRr8NaclHNwm1ZQcPgUp/+zpOJGFaXb5qI6Kdj+/yMqqOrekSzbywRPhigem rrJPTfEDJYxk5siOi5sIUBLpbuxTA9gBchd8MQlr3Hzf6PVdZOHp05BpDpk+paaA9lNViH EcisrwM5h0mn4d6uF3aII+DjxtkdRN0= Received: by mail-ed1-f48.google.com with SMTP id w9so53879246edc.3 for ; Tue, 28 Mar 2023 12:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680030156; 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=sg40HJuMXcACzrQyQIiyBgX+jk4GkAV6HLHPK6bGfcI=; b=F94AXc7U8n866HMI7L7KjxQgYXVxKEX1ufZhLwHPtFEsEhbsNJOSdVF8YWOeQ5aLM0 HoT7pL2IYk/Ka8HSv4wRc8DPoT9LKGU6kC4eUXtYi4KUjsKzWtw4NZ0JaC2zi57+SF9k PZDqO2+41We+vRG0DYNvfpsaofVI5scLONmPNLIPDmXr/Foh6mQni79zrX9y5N5of5mh 5ruvaxWuRzvpwbFzcBYAzS0m72Fpi2h8g9X9p1A8DJ19cKXspZUb0AuiRNq2QOi8K+0j Jqq1L/VZN5Xy8eCU5G6hlRGZ7juOLMyupEtnc+rDhXRk3QeAqm8+9lQ6D3XqDbxU9TST VUwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680030156; 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=sg40HJuMXcACzrQyQIiyBgX+jk4GkAV6HLHPK6bGfcI=; b=JCIqQyuxhZo5PV2iH+zWRYasvWZccPBO1nYc2/AQAiedDL0odUf98LkvuNHZYreTL2 KVbV/enMYpCiVaNZyiSGnqBpamZwBDb88lS9o9Ko2OtiMdHpCm6zz6SzfWFBs8mQnJsp dTuB14PCy3Pk+uQN68mHRm2R8nnSLLKFH0X/9wwfxEnLHc25ENazxMF8arZ++maF1Jpq DhDEkgpXwcUYsKi2lhcpnZt6otczRDt9z/xDQgDB1nUUpCBMM+7A5ERN93Kx94JaI2c6 QS2pZ+n/OgmvOckmg5rhD8q5rqvoXuhsubxWL0DzkcuW4EAtghpEhFRHyWrjKpJ85/0C xQ7g== X-Gm-Message-State: AAQBX9dqIoCvwphJubS9LQENOE/7TvN+vfRupvParGDJhTqgnmRFU+PP MgjVnXq04JRksVvlXJrDkuhZOoNAzC8JhrAXRuMluA== X-Google-Smtp-Source: AKy350b9CmCnhINIvZWCyCyiJq5/yj1sR/7xu3MCLvibXTNZZv84Tr+hYeSE+IrQB4ragBIAsfNUY+4K5SHaoCEArvM= X-Received: by 2002:a17:906:a86:b0:933:f6e8:26d9 with SMTP id y6-20020a1709060a8600b00933f6e826d9mr8602763ejf.15.1680030155943; Tue, 28 Mar 2023 12:02:35 -0700 (PDT) MIME-Version: 1.0 References: <20230328061638.203420-1-yosryahmed@google.com> <20230328061638.203420-9-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 28 Mar 2023 12:01:59 -0700 Message-ID: Subject: Re: [PATCH v1 8/9] vmscan: memcg: sleep when flushing stats during reclaim 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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 66mstam8n1p6nyrtjnw7kxysbzfe4aan X-Rspamd-Queue-Id: 6CBADA0016 X-HE-Tag: 1680030157-954483 X-HE-Meta: U2FsdGVkX19Qz7+vRTc3yP7x6QXbKWnaStskYrd5hEo8MnWN9eoS2MXkdbdorhNsZUbjGdh4DusHnPArJ6wEsO3D5c3wPOzKrnhYWpoE5iTBZy/RGer/UreH4PMOJyHByXxnW26uZqx8ntcpHfXK5xLbfoPEU/NY5GURrGv+GkQKjXf/fqted4O6T3/c7KL3fdsyhxYCc5KS1lBIpU4+Y1W9JlrYo8U2nc1TWK/PH/Jeb3oIBmTRTQ6nU+4d/xv8QzhJ2LgEaRqd7Z6937wRdLr8RlFky2Ry3y6Tn3nG8vUgOhAzhKwAWZdIT+TSlkpTmaxs42QkWblrseSxPYJLWqnAqwE+W3i9xokMlLdb6z3EYyfvbY2TSf/+2YWhQwU7atdkD6uEQfGzIoS7Q4qpE+2pQyHtgzaY94hkoJKu+stQqNbqlrFijgLCtMgZSCA6EMTAEzZ/HjgKiiptkffKqtpEJUGsp7iTxJYnqo09R7iG/8g6Yrst/S0r9a/EXLljuvxSyoP55dUEFDdP+kC5P+1NqkSv/bdm3wVFhVHzmepofAzOTMEcBBDoxmTKWFrMcbSxJ641D+FGCU9AW+GdtPas9/4WwquQmpy4ioR+wfT9ZQc5dEh/bZrqEYEwspZMX+zfoJ6HjV/+M3hM0dJoQ3+nNplbHEFSLor5Xd+Kkb2VrXRx20co3Jodq9YBfoAmt3f/lX4vWYJn7+WRWjXIY+sx+Nd9SWTg1ZblfLBcnZ/mSUxo7RsfoveLNnRwar5AyJTBuIz5PiTYRqwTmVNYVpMZvxFoNJwfK1Bd6JIXV3kOSnFLi2hGvPujA7GyWKqQkp54QU0LVYBQoCaqDeVVd9hGJAsi8pMziRq2ON48z5M3hJhMPqvBeKIS0bHz0pqzLDLeEB89V8mDJ9E7bpdTtGkWo/zr0ADPPrc4C6BFhq/LM8UN/7/IwGbTxe2myiTPES3IY5hR+cqffeTppl1 ZUveZ4HH yPybapa1uKXakNm2BZ+CPQO72LYU6nvI32+4/zLXIMiZCHMvVuc3p5Q1ceR4RgGLbzHUC6LnTXPfJ+VOJywAq37SQ/zaMh0+lXuIwP4C/3ExYjnRXbs8U4a1ehhvu+1X6u3avftgkG+akb0pzO3F/NH+lg6zFneE0Ee7/ndPtaxl7h6ChstbTZD0OnbWrN1aGIe4sfaPX0mbHYaEF3u7jlTRjNT5gbCLQJWgExVPTysjeN5zqFk651dMPjstSVSom2bcv7/csO45yENkpLe7OdC+iPBJdvBiGXliaQRb2cPupneHDvSZdrBZQIA== 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 Tue, Mar 28, 2023 at 8:19=E2=80=AFAM Shakeel Butt = wrote: > > On Mon, Mar 27, 2023 at 11:16=E2=80=AFPM Yosry Ahmed wrote: > > > > Memory reclaim is a sleepable context. Allow sleeping when flushing > > memcg stats to avoid unnecessarily performing a lot of work without > > sleeping. This can slow down reclaim code if flushing stats is taking > > too long, but there is already multiple cond_resched()'s in reclaim > > code. > > > > Signed-off-by: Yosry Ahmed > > Acked-by: Shakeel Butt > > > --- > > mm/vmscan.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index a9511ccb936f..9c1c5e8b24b8 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, = struct scan_control *sc) > > * Flush the memory cgroup stats, so that we read accurate per-= memcg > > * lruvec stats for heuristics. > > */ > > - mem_cgroup_flush_stats_atomic(); > > + mem_cgroup_flush_stats(); > > I wonder if we should just replace this with > mem_cgroup_flush_stats_ratelimited(). Thanks for taking a look! I was hesitant about doing this because the flush call is inside the retry loop, and it seems like we want to get fresh stats on each retry. It seems very likely that we end up not flushing between retries with mem_cgroup_flush_stats_ratelimited(). Maybe change it if we observe problems with non-atomic flushing?