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 39E77C001B0 for ; Tue, 15 Aug 2023 00:18:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69768900010; Mon, 14 Aug 2023 20:18:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6477090000B; Mon, 14 Aug 2023 20:18:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50F65900010; Mon, 14 Aug 2023 20:18:37 -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 4113C90000B for ; Mon, 14 Aug 2023 20:18:37 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 09F3216064F for ; Tue, 15 Aug 2023 00:18:37 +0000 (UTC) X-FDA: 81124427874.14.ACD289A Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf02.hostedemail.com (Postfix) with ESMTP id 1A08B80015 for ; Tue, 15 Aug 2023 00:18:34 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ZetMe4wD; spf=pass (imf02.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692058715; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iI/z3p1z+oyuvkMoGO3dhSMxAz4pa3XR9N0pfdyH1rA=; b=ohCCYJ+OY0d/zv5gMEiByBlvp+3+PIRknlzh8qntEskXl0B/FFsTVviQN/EI9vgV2mBBp+ Lq4oMQgUmjCdHZtOuX4lt4MT1h6WE5fgPO6kL8dkyeEsvnwvYvhdrmGfAx/P+KPAiHeBoJ 17z64EuSFIeG3JJhrEmIzxAVoUL9qmY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692058715; a=rsa-sha256; cv=none; b=kKg642iNx0/oQart6iiRIDbBkn+EYLEV+BorA3IcxKDD72klFAcphth7tvHF9sv3kExXCx FkDrtjrCYG4YHaAtiYkvDXYGBP+ek+2hajz9HeznemRvVhlzIk3g8xJ84/PEb1FErSd3wk aGfYzWONfnMsPtDUDZk8UnUc342iLCQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ZetMe4wD; spf=pass (imf02.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=htejun@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-68783004143so3165746b3a.2 for ; Mon, 14 Aug 2023 17:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692058714; x=1692663514; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=iI/z3p1z+oyuvkMoGO3dhSMxAz4pa3XR9N0pfdyH1rA=; b=ZetMe4wDM/zQ8LujISpxiJVpdhExK6n4UGgEYvahiHieWe6yvAO7zOlZjAC4rxGbwY g9SSYLFu5SjRyBybonkHUitUBuUvIQfMnTG7/Gyyj2c6NYX/Q4pbztzk9ZD/hIlHO9Dy hzLIsjmH1AezKGQfiDXTcKQmND/UMj7JD5sUVN27ODMpHKC9P5wTJspfkuj1SINQIm0U 2Ye1n8dCGUvAEU68VXJ2qZ0uWcqjcFETeQQD94DHYJEtIodWwMujb3desP5BXnCnwY9K MqGr+SM97wwe6DnNprIF1WgArQITtdv5QCv290li2MZYGkyzF7V8Sbn1B/tB3dAMZJTQ 56fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692058714; x=1692663514; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iI/z3p1z+oyuvkMoGO3dhSMxAz4pa3XR9N0pfdyH1rA=; b=W+IeLrR/kGDOfgnLZ04TNLhnlz9xz7IEiHlNkxnLsKVOF/PIqOOpQ1SUbzKTfkGgu1 idU1Tlf6tGG6ZkVCZDIJlRBfWZsyI6jBleUpfqrXghBr32xsV5fuwsl0fROd61IzWi+3 i20TDeLbSDBkwAj0zjKt2K0EV99oYFXvawjIzuNC3cJc30TDWZ86gfcGYnwjDAqjU5+v Z1FuEXCe/xEFsL7aOjPsfHhpR+TaMIk6n341/rgOUTCdmI7ol+1Y3568pTQRjbZ0aRn4 1V+nx+wePnNR0wgMofOe/p7tn7/mPnP1RAnat7mieZGYzBJSSUVzjkd0GpqBSL5r2qB7 CcPQ== X-Gm-Message-State: AOJu0YweTmBpwyvJxiWbhPoJqnNqi4PbEwDUwXGuiJuopu4Wu40o2sPg tSTqMczgYVREd/oCDv9XyQA= X-Google-Smtp-Source: AGHT+IEWCm2HUHkuK+xVRs3xx51ddukSML0RqtZ2nwhY4h6+zSHUXkqdaKAjIFhWZ13SsnxPXmuHqw== X-Received: by 2002:a05:6a00:8cc:b0:688:48a9:c4ad with SMTP id s12-20020a056a0008cc00b0068848a9c4admr315573pfu.15.1692058713730; Mon, 14 Aug 2023 17:18:33 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:93bd]) by smtp.gmail.com with ESMTPSA id x5-20020aa793a5000000b00682ad3613eesm8422492pff.51.2023.08.14.17.18.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Aug 2023 17:18:33 -0700 (PDT) Date: Mon, 14 Aug 2023 14:18:31 -1000 From: Tejun Heo To: Yosry Ahmed Cc: Ivan Babrou , Waiman Long , Shakeel Butt , cgroups@vger.kernel.org, Linux MM , kernel-team , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , linux-kernel Subject: Re: Expensive memory.stat + cpu.stat reads Message-ID: References: <20230706062045.xwmwns7cm4fxd7iu@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: wf9uqkxm579wjjumtm9shdf6p77ruiy8 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1A08B80015 X-Rspam-User: X-HE-Tag: 1692058714-601462 X-HE-Meta: U2FsdGVkX18m/FdouPol2/JVeVG5Sio8tD8qgd2YuCGDOkd+i8tEheQlnhq1sq82NSK6R20ix3SVfqnuCxUadp1ZpetZIBQETOmPOIB2Vrul2/pls5iLh5oGrbG+99GW/z4/5KWvvyW2MBV8fq0n2fvtlu6+0LjZAu+UELRAu93Rb0qGmVkp70lWqnkx12f58LzeKTfMG2HxiyAMdoHqTvVyrJnSa9xPcO/SS7xuUvaNJm52Tqz+ghB3Ov5TrjbyOSXn2UiSet0bWbG97YZIf6+Kk3AOarrSQQej+Lfxe06GpyI9WBq0amQNHP5uoyTwqVyp13voSbRD62CtO7xuPnfVK4J3v6cxMfOS+foPcOp6SI+M7IytKqQ34X0+LGWhpEglK0iWsTkcF6UloJ/+r4yNN+6HKfV172GdGSVtNZEh83Ju8MDnWSqPwa9vCDrHEJjW4vV3+8TLOpj1gZJE8uRGyStw08M6uvlS2ufj3EiUbbZLfVNQ/KVZ2NJrvdmFBl6Bsy4zMCQTfwnjNn+tsvNIlxPRD2SzfEuVAwkQaEHXD5b5mfXEE7Epwp41F3M6tztwF2Bf3DHaywc/JPri9YWcrJz9D14p9HzgGPB0VMhRgiSVvEfQL8gQxgApeENcbjaQdmAdIoilYduMXIw5oYVyWgFQ3YINimmieuofi7+d38+d09pXhck0JPxg4YO+ykHGeJoFI/qTdUQGAxlgKTzv1P0+1xFK3v9/npDbZdvmN9OWCTytwURGBC8ONuHnY5wCoF6HItbTCw0tryCiMgkVkgiMAE2ev/3TL49lVrCNsuiXUJjCc4tANeoAsKkgxh99K3CyKhKufoDXSDoOuSq+YbFm1ON4Wj4z4s4cA+gSseN7jpHBzBdJ2vZyxd/KyX2bc90GKoWGlKww8ea+sD5aPOYPj13ZqA6tqawrWLBaW2DOwfy5RqQKL8fsh97Ys03lMz8Re8SmE8gHNr0 t3WDrDRc mGhRKNytYMqK9sJTj6xUBYeQ+qHxaFpFeFBvbh1s8KA+7KgGL4a5zhfdMIEQox80JDczkzkaKLeUgcUzP06dJKW+Adcd7WuZP8SBKx6Si+IxjJOHqnymt1Z+9qM7Q/a1wFPRg8us4aqEYllRf7X41XG9VfrFChgqFin1b+QtgoS/LyaEWtr2v3tpw8P4VFz2I3d9uJs/cjkYrl2kJhfz9+/+Lw6F8+0sXGEU4vH/livG6ZsOIOJuYzYsF+lGMh6jnm6DSIgrDq+2yd7UWnL/gkNElmIOVGO8sHIMrFQFgKRWZhGvkll4vmhWGWMx3+ymdTGqOqjZuzvMDraappcSYu5I53DiUZl8Ty/VXLqagOkpQl1p4LFM0PGgEpVP7Y9A6DQ/tS3TQ2GjL7/gOCurDOxD9DDL++SGdQagA9tG1gEjiVckYpOKC+tELLk3O/WufSFNreckZzdePr9fny6ALe1vnZziG6qUBS+YCuW3ZGymfJFnriNWaGZPoMhSScW/hlxyO 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: Hello, On Fri, Aug 11, 2023 at 05:01:08PM -0700, Yosry Ahmed wrote: > There have been a lot of problems coming from this global rstat lock: > hard lockups (when we used to flush atomically), unified flushing > being expensive, skipping flushing being inaccurate, etc. > > I wonder if it's time to rethink this lock and break it down into > granular locks. Perhaps a per-cgroup lock, and develop a locking > scheme where you always lock a parent then a child, then flush the > child and unlock it and move to the next child, etc. This will allow > concurrent flushing of non-root cgroups. Even when flushing the root, > if we flush all its children first without locking the root, then only > lock the root when flushing the top-level children, then some level of > concurrency can be achieved. > > Maybe this is too complicated, I never tried to implement it, but I > have been bouncing around this idea in my head for a while now. > > We can also split the update tree per controller. As far as I can tell > there is no reason to flush cpu stats for example when someone wants > to read memory stats. There's another thread. Let's continue there but I'm a bit skeptical whether splitting the lock is a good solution here. Regardless of locking, we don't want to run in an atomic context for that long anwyay. Thanks. -- tejun