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 7F640C77B62 for ; Tue, 4 Apr 2023 18:09:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D20786B0071; Tue, 4 Apr 2023 14:09:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD0CB6B0074; Tue, 4 Apr 2023 14:09:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B980D6B0075; Tue, 4 Apr 2023 14:09:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A5D426B0071 for ; Tue, 4 Apr 2023 14:09:43 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6534D160299 for ; Tue, 4 Apr 2023 18:09:43 +0000 (UTC) X-FDA: 80644496646.13.D0FC015 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf22.hostedemail.com (Postfix) with ESMTP id 5042FC002D for ; Tue, 4 Apr 2023 18:09:40 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZUkn+vMm; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680631780; 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=B52t2fmF0ydFLoktH3nuFhcnoqrXavrVtQZskikW6K4=; b=tVwFQ6WFPCYLnHF0ZnFzuVo5DDWSJGmODDaVCtQBe4T79OnXHtPDFesOpXbuS1Xi5OBbDa FV7lW4Ei5OY7v5MJTHSjm0G2d+ArTeiXVIJQnjEE+jb2Sx1eZjQy+ObtkGzRgjC2UIOh26 f8z61JRxNFi3gZUadypxlLjUQQZTjCA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZUkn+vMm; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680631780; a=rsa-sha256; cv=none; b=fKpz2l5v2LqD3OUT/lh4ZRjjrANkdE8F7jzpsLkMtnE7sFvkqF7VE20zz73gZp0plPhepJ vDSDQpvaSOBK8+p/dJT8PdIK09Twaq2o5SeutCSdEQSd+xVmQb3FB/iG7wZxMwFSFuN8Nm KBecZY3KHxpydHl6PVqUeu7wHx4WDeE= Received: by mail-ed1-f43.google.com with SMTP id w9so134131698edc.3 for ; Tue, 04 Apr 2023 11:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680631779; 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=B52t2fmF0ydFLoktH3nuFhcnoqrXavrVtQZskikW6K4=; b=ZUkn+vMmRDV0gsBTGXHogd0b1TEWeQRRSmXdQcA8YCbW4EuVBBVzWtXP1bseb8UKG4 HJDAAsbeXjYwlGTq1GOQHa4KVIiS7AVj1arrMSDEu8cZLrnSvtzL29WGP876gNKX0FLM R8P9SFqsaEyYhbbck6gl7U+wfPr72XBPHHa+ziXeunDyh9RAQFmIOPxn/sLtUCoxKW8a J1BdHwp4szCI6HacbQjAk3Y454DHt3ONjUeVbcPTrpQt9VyfkRUyBrcc8jVO1AZ2tR4e 1vv98LykBrkR7LWxMPMMrceWD1fqi3G5sA/UdA1GtjX6t0I617WwA0FZIzFiWLDPe/6/ +B7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680631779; 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=B52t2fmF0ydFLoktH3nuFhcnoqrXavrVtQZskikW6K4=; b=PAMYIcAlqDjEhakbR4n3XFCjBn1jESnu/h/ILNh1FFvq0/HTbp+g0s1XYzjmb6x0pq S9yrD+B1BdCHlxDsO/9SCAe443tA9vp0WyKazPSjKDWRJxRKSwHfEa+2zSybn4kWOeQU dG0uihPhWbfFjQFPxkaTZPkVmZA252oyO354eQKTxfiTbkr/2YAK/NMVg2pVHt72O6Av oKkCpuWi1ByUN+vweibDG7doBPbBAsmJkcbXg373q9+NCNRsrejiHRqdoXS/YGBH0QfG C71iUL0KjuGdbScjqf6h0QBaAt/v+c72KnArsNx8blHjVavvuqKqvsXp5eDy4ojc9VMi nt4g== X-Gm-Message-State: AAQBX9fht+wR0bBNJcCWj8l0VL7s/6fJYXaaQWPTjmhVAwjWejDqWW9a LiugNtmChmdc2e805sl+bEfN7xw82VLVlSDdGtVgXQ== X-Google-Smtp-Source: AKy350ZxaFc/uKVStdfwkk4WcI7qsM265x5mfy3cnNJzn3+MXngPFkg4fAUhp6xtZTUpsRfDLKUL6KUidnazS9zjh4s= X-Received: by 2002:a17:906:af6b:b0:931:6e39:3d0b with SMTP id os11-20020a170906af6b00b009316e393d0bmr192993ejb.15.1680631778633; Tue, 04 Apr 2023 11:09:38 -0700 (PDT) MIME-Version: 1.0 References: <20230330191801.1967435-1-yosryahmed@google.com> <20230330191801.1967435-7-yosryahmed@google.com> <20230404165305.ffs7uscqpndnfytn@blackpad> In-Reply-To: <20230404165305.ffs7uscqpndnfytn@blackpad> From: Yosry Ahmed Date: Tue, 4 Apr 2023 11:09:02 -0700 Message-ID: Subject: Re: [PATCH v3 6/8] workingset: memcg: sleep when flushing stats in workingset_refault() To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Tejun Heo , Josef Bacik , Jens Axboe , Zefan Li , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Vasily Averin , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5042FC002D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 6eie1xkiirx4586383jj341jjyi7f6dk X-HE-Tag: 1680631780-465654 X-HE-Meta: U2FsdGVkX1+7PXCGBf0n1++CC4VRBPnaqxtXbDMOelHsQKdlwJIE6VBJUOGe0Gk+5LKJ4cgMrtKhIKXdH4NKv4P71STvsKPg7fYEY1tBHr7v5a8RcwebuLNJQs946KL0FgEkQ4IQgRN290v99L0AUedZKIf9zzsy4P/43Dz/zQnv7UDrFStWhSkC6fHtys03wLcxzwb+sqcrvcNPPTBbs8DPNzs7DXgTmStct1sOObDQBLhs6Gdc50npF/4k2gMDPP5eNxwbOT6mlkj5LtB/QsN8qfRLA6D1Bl/b3qOYeGUQK/iY5CXYqtdNlJ9HJpL4GjCUgbCfj7LyD/RVRUfwmHM+80/PPcl6qMJgSOCfQLNQj3/9Id1tVp8Fu88zsBtRZOAB7PYGJRkl95CSctkREASx1SSUe6vnaRqIxnzEuGe5nvLqKdRc4CYCbXL3z0N6kzeM3eDvyOVrzuRv5hwGZuWqKq+T1vokd6x0K+FKID9V0AhwNqWD6Au/bM/8Ol/5et264fBmN+QPWxiobrJwKGjGBKptgUzUlrdMwu7EXyxb5ZhpwhrCr0os1sOuZriPzdOO5Oifqbjz5PXjKpmxp1aQ6UotSeOXKpzrcLYM6Tkuq3AnglHNPFJCC3Idg4qmr6eBzbyzG3jApSV1rG6FQvTJP9RPfgShycvHfgwj5J2GA70OVEjJo5gvrK5nQb6F5iJyevq5/UF5dEI0FxGBq5aV4HuiNAAWSNyAgHR6AB1pKgOSLhSh0k1ZD0qNChOnbkXMhBtWQkKtoWj5nMtekSs9RbiDIs00RgRsP0gJ3qpBaRTUmzzXUQYjfXtX5kX9eUrKS01hyRh77jLsS4FTkUL4GYJq9iUa/7a0BJF6TBbjLGsKsxmqNBUUs4B/a4XPj0BONenJ4VZG4G+h2Pq5vAiJIOqRHoNOk2qQBgV5tJgPIioNjdz3eWf6Z6PBVm5/CzZb07ivwrDlGF+Na+k NskerCm+ SuGTOir9OyjmATYAnptpr5diB/nhv3V8l/wtjTvO522h5sPkbni6I3p+yGameOvmeXZGfVDcnQqWJ0cBjblX9PlnLm8Idalv6tfhM2DNaf1EW69fu9UG3snq7iVvOxtWtuamoWfTf56CWFSYTX3EJQU6rZ7EDUEc4VXFosh6mZRIafjwEHQU+WYkrRIBJl9XxQCyMs9HKDwFXWs4LMTO6vkcqh2MKx9P3CSL5MQHfMIt9uRBdh3uU+DADTtzfMbNm1ocrRsc1P1Mv2kTk0dhgUXMqWW9IgQhsn1yPunr9X9rbUtd5dska3G0TVN5c74a6h8y2EzIYr/tmqfoV+hnbvd/bSKAnjqbYyiXpbsFGj7rsun7WHgTKCCuKLQ== 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, Apr 4, 2023 at 9:53=E2=80=AFAM Michal Koutn=C3=BD wrote: > > On Thu, Mar 30, 2023 at 07:17:59PM +0000, Yosry Ahmed wrote: > > In workingset_refault(), we call > > mem_cgroup_flush_stats_atomic_ratelimited() to read accurate stats > > within an RCU read section and with sleeping disallowed. Move the > > call above the RCU read section to make it non-atomic. > > > > Flushing is an expensive operation that scales with the number of cpus > > and the number of cgroups in the system, so avoid doing it atomically > > where possible. > > I understand why one does not process the whole flushing load in one go > in general. > However, I remember there were reports of workingset_refault() being > sensitive to latencies (hence the ratelimited call was created). > > Is there any consideration on impact of this here? > (Or are there other cond_resched() precendents on this path? Should it > be mentioned like in the vmscan (7/8) commit?) IIUC there are multiple places where we can sleep in this path, we can sleep waiting for a page to be read from disk, we can sleep during allocating the page to read into, and IIUC the allocations on the fault path can even run into reclaim, going into the vmscan code. So there are precedents, but I am not sure if that's enough argument. I did some light performance testing and I did not notice any regressions (i.e concurrent processes faulting memory with a lot of cgroups/cpus), but this change is done intentionally in a separate patch so that it's easy to revert if regressions are reported. > > Thanks, > Michal