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 1BC0CCA0EC3 for ; Tue, 12 Sep 2023 11:10:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4166B00DA; Tue, 12 Sep 2023 07:10:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 793646B00DB; Tue, 12 Sep 2023 07:10:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 683476B00DC; Tue, 12 Sep 2023 07:10:11 -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 57AFB6B00DA for ; Tue, 12 Sep 2023 07:10:11 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 187A840E10 for ; Tue, 12 Sep 2023 11:10:11 +0000 (UTC) X-FDA: 81227676222.09.663CF1E Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf12.hostedemail.com (Postfix) with ESMTP id 2D3844000C for ; Tue, 12 Sep 2023 11:10:08 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QrD5a/gg"; spf=pass (imf12.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=1694517009; 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=2Sq0fA/VatZ++ayfpGlQL3susC/RviepPCleB3baLTw=; b=GsCarS8jdMu1J6g+43WrM7Eez+uvLpAKLd/vhhaI/CkrlncNmplTO+Kr7IHnDpaa+vY9/A WnIp5TuBjKOrsOGlSTxy1Dy9nWNVwcY9gYUb+WzzYe3AVJqfxDxZvIZueaYEovrBIKdb71 IsJdFW6KJcZ8G/DtygeL3OVtt+vLaUw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QrD5a/gg"; spf=pass (imf12.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=1694517009; a=rsa-sha256; cv=none; b=Vw7Au6Yl083ZYufMODrv96dz2wYgh3Y6a//hKC2BTCFLpuBWjfQfwBLW3Vw0eWIllLtTfw r8Vj5vznAZFfANzJMxcTS+FzanzQA7U58nMejLV5yyH0OJfgZrEMFy6CT90gXCnonp1ET3 5K4LaFzNpzvFCF7KI+qr19FekHbk14I= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-522bd411679so7068287a12.0 for ; Tue, 12 Sep 2023 04:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694517007; x=1695121807; darn=kvack.org; 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=2Sq0fA/VatZ++ayfpGlQL3susC/RviepPCleB3baLTw=; b=QrD5a/ggErarLAQDj/ns5aUBnOLXF6Hwczyr0WUmSm1KOxzhveuto+BKS84ILez5x9 X5KbPs5LxfCoOPdTD6jcHyC1zVzu9V1IFaOJfIIKL/ESVq77ZKWHme4lvLFVOGgOm1kP 5xYrLTCdINTQbLl+88PyPvXAU1ZsLb3lROYRk/QIoQZWQGFfPMGkcYsN5LSmtifFMqAa TB5U1Sy0A8IXfRGRv2xEVztqsFOMOGbgIYkRwiQRoTI+28Yrx4inUv7uo7WCtKZ75q73 16J/pmOqO9SN7c6qIhQmudJQB9PXCmN5xYaFIa4BkiLBjpBEcMXKhAgbkMOMQ+QbP2mk ms6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694517007; x=1695121807; 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=2Sq0fA/VatZ++ayfpGlQL3susC/RviepPCleB3baLTw=; b=VI48RjCvWmnxbldrRlutxOobi628cx5BBc7dqdAsx5UAQMUHDdoetHM4NOtVyDF84r bLJguWNQK3JszmyMNT505Ug6KZQrff15tZZmDKL/Zrlj8x6sx+vUd2GinZrv8hTWMt0/ Bwa4AFnzsy2QL1+brpQNM5tWV12kpG4LqtTfElxoMnmppCYdGoFTOh9csvIReTGVaWGa +LlpBHExCmMF7tWsOZw9ACSIKh7LjPj5QJZHTVzRcaycl8xYN5Cy+IreyxV/5SHTQdug r5qGCmn6DE08COm1BGxxMbZdfLigvUbMHqv9QW6bRkemT55MnCmdr9OFYeVc1xYUN9yk Hecg== X-Gm-Message-State: AOJu0YxhV99lMA/KGDLPm90PkxedCnR40JzZuDn1Ow3R39mKkDmyIiyM 44BAuW/JsQGuHSmwL9BTTmY2HfoGkAm3aFfJtSB/Mg== X-Google-Smtp-Source: AGHT+IEqf692PpcwWJ+KIdN9fRGhrkF5AMtPRxevzTGnCQ4lbfLrNNYioDArel+eLcA3y9SeK6u55VX/HEgsrXww4s0= X-Received: by 2002:a17:906:10dc:b0:99c:f47a:2354 with SMTP id v28-20020a17090610dc00b0099cf47a2354mr12544637ejv.70.1694517007270; Tue, 12 Sep 2023 04:10:07 -0700 (PDT) MIME-Version: 1.0 References: <20230831165611.2610118-1-yosryahmed@google.com> <20230831165611.2610118-5-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 12 Sep 2023 04:09:28 -0700 Message-ID: Subject: Re: [PATCH v4 4/4] mm: memcg: use non-unified stats flushing for userspace reads To: Michal Hocko Cc: Tejun Heo , Wei Xu , Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Thelen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2D3844000C X-Rspam-User: X-Stat-Signature: jciaub5yt8tijpt9ibp98118n5rqhbyh X-Rspamd-Server: rspam01 X-HE-Tag: 1694517008-779761 X-HE-Meta: U2FsdGVkX194zS05UmEUR5eqqN8t7/cEuBTpBNB7HOFpcNycx0YTVN9nY2LeO3NnmlG81z8ImW3qq/epLKNzwSo1nUZUlst5Y1keEhZXNlk3efMI3xRucEqOazTGe8lxLhKF8xNjVmw4IsvUf2rFEBreviOH/WF57tjH5cA/L7XeminqrcBCgRfcgxeR8PeSRK6HKoYwt7sxDvQpsk424OkTLoHuZABDLNcCc4sv0vITo+d75I4357LxqxEyzNfNWD7gonxbvNwAm5nW2aYMzGou9csg72VW/LCl0t3xXD2xSBLLtF/9EjMJ8kmusoiBgmWtu/Tuh8c86eruWQD409m4w6LPteK/83t+OZR3e/pfTIpwFyBFg0koInSKked2wHVHuyX76HurtgzbUf6REYtYQZODmUnDq6pCshqxzJcLdo5rEDrI1PTVNz1eIT7K/GDNQ7ryK/biRLyxxyzUC4CekJQGwZuW0Qcl1rt4tYnPIoO9wEYQlV2aEwzVlvmjVXr1sgU0E7tcmAKmQ3kff7yHpi0P82ip49p41H0SMSCxpLyMDn8J9ybTOlnB+WnMrkvA7DVrWpJs1kVUQNhebSdixC7ObWPp1D7HgomatiFTBIbiVwQwWGcCqs5/wITsTIkWT7N6hZUF2YhrVCGuDwYDx1SdmE2lzwJgJaMMg5kvc/FojBPWybTQFeZj5LXipFSCy44626KfHN+ndvmeB8J9EFs6NBKV/Di1Hop2n4Kx7GZ83glFKorMoDdY+96pCdTdU999Y/wtq9tKEVUiJ99oNa0AL2zRj3I34m+SoLByatrESIIzyB57VyLtulczu1f9ogy9SkpJCYfGN3ke5IKl4s5j9NUQYhYkTG8JY0DeeCFDCRQDG7h7UZxxEe6Vv1s1+/FIOfWTiN4eI+v3IJHRm1h+GS764iNnoXZehS8mQ9BOYT6cTjZUDiQUdxYtvxAkCdTAfuZHp5MKuM+ KmSNhfOp gk4EIXF8Y609yi3+X4qudxlPIyCgBUH1aLh0JvTL0yuqnTKZCHsZOzgm4tCiUNR9koRs3TSHFe0Ql8+wDN7bNznseBt+ii5ZS9GG0k5resWEYtx815D5pe1tnqCH261zuCtQYMewaIhEY89DXE3lUFIbDZXnbhjatfUYi5cf/XhePN7VnHHhY8AmklDSWUiNP9yU67e1RDHOZr7qWKr6zV/iQLMY1r5rzao8nqPVd+0lwoUPTQG2jXdug/BhlHC+mBnXARyBgSPp6sieAFIhfwqzjU+aDguoE4upJ 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, Sep 12, 2023 at 4:03=E2=80=AFAM Michal Hocko wrot= e: > > On Mon 11-09-23 10:21:24, Tejun Heo wrote: > > Hello, > > > > On Mon, Sep 11, 2023 at 01:01:25PM -0700, Wei Xu wrote: > > > Yes, it is the same test (10K contending readers). The kernel change > > > is to remove stats_user_flush_mutex from mem_cgroup_user_flush_stats(= ) > > > so that the concurrent mem_cgroup_user_flush_stats() requests directl= y > > > contend on cgroup_rstat_lock in cgroup_rstat_flush(). > > > > I don't think it'd be a good idea to twist rstat and other kernel inter= nal > > code to accommodate 10k parallel readers. > > I didn't mean to suggest optimizing for this specific scenario. I was > mostly curious whether the pathological case of unbound high latency due > to lock dropping is easy to trigger by huge number of readers. It seems > it is not and the mutex might not be really needed as a prevention. > > > If we want to support that, let's > > explicitly support that by implementing better batching in the read pat= h. > > Well, we need to be able to handle those situations because stat files > are generally readable and we do not want unrelated workloads to > influence each other heavily through this path. I am working on a complete rework of this series based on the feedback I got from Wei and the discussions here. I think I have something simpler and more generic, and doesn't proliferate the number of flushing variants we have. I am running some tests right now and will share it as soon as I can. It should address the high concurrency use case without adding a lot of complexity. It basically involves a fast path where we only flush the needed subtree if there's no contention, and a slow path where we coalesce all flushing requests, and everyone just waits for a single flush to complete (without spinning or contending on any locks). I am trying to use this generic mechanism for both userspace reads and in-kernel flushers. I am making sure in-kernel flushers do not regress. > > [...] > > > When you have that many concurrent readers, most of them won't need to > > actually flush. > > Agreed! > -- > Michal Hocko > SUSE Labs