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 01D4FC71153 for ; Mon, 28 Aug 2023 17:08:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7672B28001D; Mon, 28 Aug 2023 13:08:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7175E28001C; Mon, 28 Aug 2023 13:08:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6063B28001D; Mon, 28 Aug 2023 13:08:29 -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 52B2E28001C for ; Mon, 28 Aug 2023 13:08:29 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0BD93804FF for ; Mon, 28 Aug 2023 17:08:29 +0000 (UTC) X-FDA: 81174147138.24.D9D5FFB Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf17.hostedemail.com (Postfix) with ESMTP id E5F7840027 for ; Mon, 28 Aug 2023 17:08:26 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=iFiaXdvN; spf=pass (imf17.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 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=1693242507; 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=CgmSxEVlzi5fMkwnrM8LhIHtQEbm/jAUKGlrVKGkYss=; b=lWsCbiB3DlgWcWslJdFfrWivAUku96SWJA/E3+fugWtVRhOzYJjZtldB2jEY5WZev+PbYf rAWkAIhfWx0ZnvLMDWpOCEb8Q+WgdhKSe4rpBx5/juffY49XHBOUL7PWTpSX6+caF5Bt0T bbBhofDxPJGOvvejNsw3y8J8TYJO4mQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693242507; a=rsa-sha256; cv=none; b=clgN85/46z4PdlMRKZZjIHCqFWfhTD9nB8UQlIgv4L+ltLN8hWyUA57XLHXwkGJrW78DSf aHjRseAZkO6Ogu5Gi2nqhuoU8VROP1rqv5yvdavmphSBs1yhjfKNd99EIQ1IowMWyLvZ1/ wDLEwqgURd8KAy+gFgEk+IKTsRrSbAI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=iFiaXdvN; spf=pass (imf17.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-99cce6f7de2so446352766b.3 for ; Mon, 28 Aug 2023 10:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693242505; x=1693847305; 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=CgmSxEVlzi5fMkwnrM8LhIHtQEbm/jAUKGlrVKGkYss=; b=iFiaXdvNyP/PGupmYZQ4VDhihu4roD+VOTAYUOk648A8zr/NnetU0xeTBrkoG+AsPR 2wxI9+4xAQyl3Xxl94EeAyF+UIHsPMJF7wGK0pCn3gzC4W2F4540PibPlUl5Zn6MTaR2 o9vymucc9ynm4RNh82v145GN+bLsUwc0gP3U/tWXkGAjscoX/fm2tFx7pnKGjTA5r+bw 1SR9g8zkzT/uibLlIedBK0SvUKoCFVbB3i1kaLcB1K4BYwKWqBKKzLSRxsgdcTYodIoi FusqkfeL0/iUTIn/J+n7J3p1yNB/tRDgBAeMhHmPuu5uQZq3RL4xZ0uTD5pWqvRs5dNW PSjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693242505; x=1693847305; 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=CgmSxEVlzi5fMkwnrM8LhIHtQEbm/jAUKGlrVKGkYss=; b=LslfU56pJN4WNu7+U/Nhoy8QSFDTFoFgCKJvGn1e4j2158Q1E6tmhlFhYFo+ylkdit U0odNiHrqb8EpMdtCivEfZoRJxJhJjQLgXlxMYVXQFg5NxD9/h7S3NJRdtQj0Y3kkwG1 sj7p/jxcpBniucvV4dGqAHNvp7s5t9ZrAiaa32mx0HyUlxc8yv+IyO38ahVi1fwkvSfo V8nU2ffJc0F27oNppRjgmsUCXDK5sN88Vs1VTfmMGXesrwzuqdTQo3XJdjbWSTtXQXz1 HQwl2CsX3yqxEtFh6SLSjvLcK9FjKeR9YUDUKa76ytLA2saA1+yDUb2lCEDoPwv55601 gDzQ== X-Gm-Message-State: AOJu0YzKRZgHKg2kBLnhVifbdeR+b7FLLSmYWgL/wAveuNHHIavlNAvS ZUbU1k1iZoV6uo0/hlShqjmtrWjdsriw5CZENzW7jw== X-Google-Smtp-Source: AGHT+IEebaOPHNuzP7D5Utx3nzTPX+fvnhl+LnF5mzhFALZEervRMpT4j2HBe8/3OWEpuNkUYvYhIzytsgarWkOfJOw= X-Received: by 2002:a17:906:2092:b0:9a5:852f:10ac with SMTP id 18-20020a170906209200b009a5852f10acmr5947834ejq.53.1693242505112; Mon, 28 Aug 2023 10:08:25 -0700 (PDT) MIME-Version: 1.0 References: <20230821205458.1764662-4-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Mon, 28 Aug 2023 10:07:48 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads To: Shakeel Butt Cc: Michal Hocko , Andrew Morton , Johannes Weiner , Roman Gushchin , Muchun Song , Ivan Babrou , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E5F7840027 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 984ipiepjmzuex44gryt43a1t3m5u55p X-HE-Tag: 1693242506-983965 X-HE-Meta: U2FsdGVkX19MPd0auX/ISFzYQjRR/l5ioHlmRU1u9Of6hrLahtnb04nlhEJKyeZoaa3qMeefMiIf/KYb0Z4NWpBJxwYbl3w5knXDv4sc6B/1PU2CvhDCyDY4j5QMJgpZZ7kxc13CcWpQsMXzRhr4kMq7sInDD3QaR5/x8nuhcSYv55/eYgShJrku1xANidSD6B1aZ9jWlrMtsoCiASiDX5LSk5tWg6NjsOKQOeY4A/IxyKu5kMFBEqReLWJqD1Dur+3hLk0Dk9ec5lQpx6iKjj/QTEOw+ScNvUAdHJEHz8tYOuW081v1SXHEGAIIOvkYV5r49rrk1y/pD+3uw7BtEBurTPPM3xIj+rMaw1yr0jXAAwBMUhhNs5pqaM6a3Sb5sE74I3U5a6MVLFPtJ8CGDu5eNYLUIoxGNFTzE/HLWEcaSt2tFyLaVEBd11NnIQEfDxxSM9c3FUvw1n/IP5WKORQCAdTgX41J5SlnwtVKyebjeUhnVBZ0o+I9nBSJosIOBLrhWwP6ZyaC5rEzRJmMGXjVik8+qietD+Fh1J/TcEklIZYkS7eUyuJ2fkTpUV+Lkn7LPu0AfrGMEVxaDv3IchgOYu/LkbYGBMuGa3FLLm6ab4LTyymhRv6q9bJSdiH0yRxXEOtXFl9N3sOz5q5Bbaymoqq/AuLLiL4TV3iUpKriTr0dLx4Aw5NoH60KdpWdycDvg1JuIpeNCWcwSHc+p4O3Bdz8bnIl0/VBm+IHv9y84oryUzIvTVb0fHqAR83MLhIDWty7U5MlQxNkA8ytgL0D4anlOT9qvqHJzCDgnfNYGVnJPdWyPAE1JWC658ErK5+KABSOvYH8K5RIvPZL4eLIdgCrKbAKtIYUd/4yAiNycLYKh7m+rYJTYvpV2z/v4U1mkvWte1qF72lSAO4AHW40cWACiwgKWu7QyyYjhwSMWTv61YLkW3a6k5Ddy/umD5lSSCAgq8jjcwVVo9s zs+rSeqc haI4tSP2yA8LOii4EB+gK/nE74aZls516A6cBANt1gilwJ0ri369C3RyE72rMpf7AgGHyAmD5Oh11Qh9oSEfW0TExz+3C2WhxN5Xqi85L16nV8VDOXrohbGKyAvBc9DwPV8YVTkOyXznG7eywbasv6MTI6RA3diaBA0IVPtUFuAbJoG+AY5Jqf/Uu/CFDXo4SY+iwFVhaoQmRGMSoukru62yigTSw7qNlyN5npQSCXC/zsFtIgaoKAiu96Q== 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 Mon, Aug 28, 2023 at 10:00=E2=80=AFAM Shakeel Butt = wrote: > > On Mon, Aug 28, 2023 at 9:15=E2=80=AFAM Yosry Ahmed wrote: > > > [...] > > > > > > Well, I really have to say that I do not like the notion that reading > > > stats is unpredictable. This just makes it really hard to use. If > > > the precision is to be sarificed then this should be preferable over > > > potentially high global lock contention. We already have that model i= n > > > place of /proc/vmstat (configurable timeout for flusher and a way to > > > flush explicitly). I appreciate you would like to have a better > > > precision but as you have explored the locking is really hard to get = rid > > > of here. > > > > Reading the stats *is* unpredictable today. In terms of > > accuracy/staleness and cost. Avoiding the flush entirely on the read > > path will surely make the cost very stable and cheap, but will make > > accuracy even less predictable. > > > > On average you would get the stats at most 2 second old, so I would > not say it is less predictable. > > > > > > > So from my POV I would prefer to avoid flushing from the stats readin= g > > > path and implement force flushing by writing to stat file. If the 2s > > > flushing interval is considered to coarse I would be OK to allow sett= ing > > > it from userspace. This way this would be more in line with /proc/vms= tat > > > which seems to be working quite well. > > > > > > If this is not accaptable or deemed a wrong approach long term then i= t > > > would be good to reonsider the current cgroup_rstat_lock at least. > > > Either by turning it into mutex or by dropping the yielding code whic= h > > > can severly affect the worst case latency AFAIU. > > > > Honestly I think it's better if we do it the other way around. We make > > flushing on the stats reading path non-unified and deterministic. That > > model also exists and is used for cpu.stat. If we find a problem with > > the locking being held from userspace, we can then remove flushing > > from the read path and add interface(s) to configure the periodic > > flusher and do a force flush. > > > > Here I agree with you. Let's go with the approach which is easy to > undo for now. Though I prefer the new explicit interface for flushing, > that step would be very hard to undo. Let's reevaluate if the proposed > approach shows negative impact on production traffic and I think > Cloudflare folks can give us the results soon. Do you prefer we also switch to using a mutex (with preemption disabled) to avoid the scenario Michal described where flushers give up the lock and sleep resulting in an unbounded wait time in the worst case?