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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E840C0015E for ; Wed, 16 Aug 2023 00:24:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240827AbjHPAYV (ORCPT ); Tue, 15 Aug 2023 20:24:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240818AbjHPAXw (ORCPT ); Tue, 15 Aug 2023 20:23:52 -0400 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 336F82117 for ; Tue, 15 Aug 2023 17:23:50 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-40c72caec5cso148581cf.0 for ; Tue, 15 Aug 2023 17:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692145429; x=1692750229; 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=qr6wnngjOfkRJLjnGKEITli6UcKrkyv5fLRjRdWwczo=; b=DmLpMxI2Z57pCltekLrtxPdsSCRhtaRsRx6F7jipwCpyI+DI4vQ9TpFFJ146R3hv/i bJTtazbPGlZFtbPAAPy9tgD1+OBMkDQMHftLu28qs6QKx9i6rbevc7AOrvCvVIIPNjZL MXAo/8+Le+4/IMGGlMO+efTHrebZsw1suOHPCaL9YhMi7djGa8RZE7ryRpmATwuzAB1e lK0aDMrJc9NrBe4WKp8o3E2p23tXEpqJ0XQPgwHQ7clyXTOFqs7XDb7azNiAzDIpOKEm ftPSgi6paVUxUPygywa60bGtqFzYdPixr0z1OE7qhQyeBABacrkxeV1Rw6WwkCdFwCFy FpjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692145429; x=1692750229; 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=qr6wnngjOfkRJLjnGKEITli6UcKrkyv5fLRjRdWwczo=; b=NrkceAhdx4j/z54vQ/bMWloIeypxpbkyJOEZEZ/yud7SzXyi4gQ3MqHAPH2EiZiGey JgYdNMoCQDSFVbsIAL225e9CVeBB3Ueyja0sBxSz/Vdcmk+Pj0zoT9bbr/qMY88wReXW vNS0j342oTHIkVyXrEkuzta4Cnx5pf2pgTqWITlflaUlO7OnrqEZG5JA+34ZOhWkDcOz kMMPoHLNdO0SNeZOUK9V5/sbrXdkR6og0HzPstgGHz1EZveMu39Yb0uDswMgJl1lk6Th j+8fK+/ogI1IJiblD4JTct+87n1R2xoOiicfFIhJzFxz5n3KktKZ78gQG5FcUZvMIXAe eWXA== X-Gm-Message-State: AOJu0Ywp1DYS4CAGsCJDtjVSJ4sCzFbTvbIllsPnrMkNQ36ReewRt9Pg m1gH9DMb1Res4SQNg/EtKflWtpyqlXADIT4T9tXpEBNzgS6wDsDgcfT+TYiQ X-Google-Smtp-Source: AGHT+IFklfKFYofmRkEJahy5j2pWJQ3aoudpaKELWl1jMcquiqD5JY5lZA5wEnQ0wKlgn5x3ziqfDjl+dKn+UyisHeY= X-Received: by 2002:a05:622a:1a06:b0:404:8218:83da with SMTP id f6-20020a05622a1a0600b00404821883damr61239qtb.1.1692145429219; Tue, 15 Aug 2023 17:23:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shakeel Butt Date: Tue, 15 Aug 2023 17:23:36 -0700 Message-ID: Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads To: Yosry Ahmed Cc: Tejun Heo , Michal Hocko , Johannes Weiner , Roman Gushchin , Andrew Morton , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ivan Babrou Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Ivan On Mon, Aug 14, 2023 at 5:51=E2=80=AFPM Yosry Ahmed = wrote: > > On Mon, Aug 14, 2023 at 5:48=E2=80=AFPM Tejun Heo wrote: > > > > Hello, > > > > On Mon, Aug 14, 2023 at 05:39:15PM -0700, Yosry Ahmed wrote: > > > I believe dropping unified flushing, if possible of course, may fix > > > both problems. > > > > Yeah, flushing the whole tree for every stat read will push up the big = O > > complexity of the operation. It shouldn't be too bad because only what'= s > > updated since the last read will need flushing but if you have a really= big > > machine with a lot of constantly active cgroups, you're still gonna fee= l it. > > So, yeah, drop that and switch the global lock to mutex and we should a= ll be > > good? > > I hope so, but I am not sure. > > The unified flushing was added initially to mitigate a thundering herd > problem from concurrent in-kernel flushers (e.g. concurrent reclaims), > but back then flushing was atomic so we had to keep the spinlock held > for a long time. I think it should be better now, but I am hoping > Shakeel will chime in since he added the unified flushing originally. > > We also need to agree on what to do about stats_flushing_threshold and > flush_next_time since they're both global now (since all flushing is > global). > I thought we already reached the decision on how to proceed here. Let me summarize what I think we should do: 1. Completely remove the sync flush from stat files read from userspace. 2. Provide a separate way/interface to explicitly flush stats for users who want more accurate stats and can pay the cost. This is similar to the stat_refresh interface. 3. Keep the 2 sec periodic stats flusher.