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 EE66CC0015E for ; Sat, 12 Aug 2023 02:48:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234085AbjHLCs3 (ORCPT ); Fri, 11 Aug 2023 22:48:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233954AbjHLCs1 (ORCPT ); Fri, 11 Aug 2023 22:48:27 -0400 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CA7730E7 for ; Fri, 11 Aug 2023 19:48:27 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-3493d0f785dso36265ab.1 for ; Fri, 11 Aug 2023 19:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691808506; x=1692413306; 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=cxwplmLw+2JXkb5WdLZaW6GfeS9OxDdNZrnocn749ls=; b=PZ2MuncHZhfjcO+ZSWYBG7AjpER7iFNiyG2mAvkgdjnqDE404SW+LGIzxTRFgtG/rA Ze5AjzQ1Yy6pxjuG/liV8H0vsgWl6cL4Vuty19T8nqFCdlUudHH28vjS+kc8KHSgVRzF S/wsfc2ATtlf3lbb8xR8qx4UFCXH+nyFivMwVpobvy+pJO9hGHi7NKsPgm9yoPhoW+g5 9ouYTGgP7V2H029wqXksIxTE8AoVWslw/7k9FdxPXjL7r9PBR87wzLF5hmNVuNueBkGL sq5YgWODSp05WxdnyzZ//RBLnSX+oNz2TaLLW5HKNsZ/qSosxxAeF3oSbrg8sY2jeIg+ eRLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691808506; x=1692413306; 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=cxwplmLw+2JXkb5WdLZaW6GfeS9OxDdNZrnocn749ls=; b=lcf3A/XyDDIuEVPoAr8G0i4UZ1Lukoj68MD5dlVMFGjAged+Z/cFAoXaC8eaKYoSzb RUNYt1fjtLRb+yhpkuzy/sRaUPs4MRneXuQKjC5DDRDFHLQFcBdEmuC5Bm+KMX9zto0g CBoZt946w/2VGIQvwKcgAGS6p6ocyd+HBGs2fz8YEWjwkcI2/uSC1jcf+ANF/mvztRTJ f0Bxzjn/SBkctF/HKlpiEozxrQ233BzIIFqhC14jqrphfsvEX/2QkK28aj8CeuKI7Ob1 qOcrbBU7MvGNk25gVCzEAVRxQLIPdTuQmyTgHma1qVHiwhuOTmDnAJD99Ta5UkkG+LQu oFDw== X-Gm-Message-State: AOJu0YzUGJeEna2Eh8uoR87Mq67sZ4Rf4HANLXjr09wKeaE092nVJ5rF eYq03JlXvGbZsxMOpfPvS0mVLuorM+9OGv/WWOFD/4DiNzbaJeoeaILITA== X-Google-Smtp-Source: AGHT+IFnzx7aA6O7TSV89X1m1NxIeDXFyw3EhhedxkxdblAh5xXKf6r7j546dl/0kV6VsxKDAEpjRluabdZ7l7IKu8Y= X-Received: by 2002:a05:6e02:1d9e:b0:349:413d:ab1f with SMTP id h30-20020a056e021d9e00b00349413dab1fmr394918ila.22.1691808506444; Fri, 11 Aug 2023 19:48:26 -0700 (PDT) MIME-Version: 1.0 References: <20230809045810.1659356-1-yosryahmed@google.com> In-Reply-To: From: Shakeel Butt Date: Fri, 11 Aug 2023 19:48:14 -0700 Message-ID: Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads To: Yosry Ahmed Cc: Michal Hocko , Johannes Weiner , Roman Gushchin , Andrew Morton , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 11, 2023 at 7:36=E2=80=AFPM Yosry Ahmed = wrote: > > On Fri, Aug 11, 2023 at 7:29=E2=80=AFPM Shakeel Butt wrote: > > > > On Fri, Aug 11, 2023 at 7:12=E2=80=AFPM Yosry Ahmed wrote: > > > > > [...] > > > > > > I am worried that writing to a stat for flushing then reading will > > > increase the staleness window which we are trying to reduce here. > > > Would it be acceptable to add a separate interface to explicitly read > > > flushed stats without having to write first? If the distinction > > > disappears in the future we can just short-circuit both interfaces. > > > > What is the acceptable staleness time window for your case? It is hard > > to imagine that a write+read will always be worse than just a read. > > Even the proposed patch can have an unintended and larger than > > expected staleness window due to some processing on > > return-to-userspace or some scheduling delay. > > Maybe I am worrying too much, we can just go for writing to > memory.stat for explicit stats refresh. > > Do we still want to go with the mutex approach Michal suggested for > do_flush_stats() to support either waiting for ongoing flushes > (mutex_lock) or skipping (mutex_trylock)? I would say keep that as a separate patch.