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 832CAC19F4F for ; Wed, 16 Aug 2023 19:08:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D28FF8D0051; Wed, 16 Aug 2023 15:08:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CDA0D8D0001; Wed, 16 Aug 2023 15:08:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7B0D8D0051; Wed, 16 Aug 2023 15:08:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A47888D0001 for ; Wed, 16 Aug 2023 15:08:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 65695C0409 for ; Wed, 16 Aug 2023 19:08:32 +0000 (UTC) X-FDA: 81130904064.19.2D514F5 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf11.hostedemail.com (Postfix) with ESMTP id 3AC7E40031 for ; Wed, 16 Aug 2023 19:08:29 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Gxeh8t9S; spf=pass (imf11.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.48 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=1692212910; 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=oW5kqtKHBtVyg+Cd9YlZqPw+sEx2elEdwRVNVT4N6wk=; b=E1sIaa+I4Efs+MweTpXZ+/q+UymOkL+J3zOR5V17edgtD6LdJ2nfM7lWJCmbaHLu2Bb2qn sYFFkPlX9IbST4dIZjD6aa81tw8JzRbsa0xiY7EqxU8csOwVZpmSLQjOnnwfhwg3VP7oEh AAuvdcu7jF78VcRj04IjqTg8lM8PlEI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Gxeh8t9S; spf=pass (imf11.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.48 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692212910; a=rsa-sha256; cv=none; b=F1p+LiK047v/qdDsVATf9PbbAw9VgvdeWOxUhtigDYO2VdtJ7MvgpUmQ00AjPY48u/+K1a +VZhNXaY4XyHxC+RO277cAhnP79WkGRScKhofSsiB7k4wIMFWAYrwnO5pK0j/7nTzNE013 Y/CTZ5ddT8j7m0y7BhIOZuK2oRnrpKo= Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-268299d5d9fso3853289a91.1 for ; Wed, 16 Aug 2023 12:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692212909; x=1692817709; 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=oW5kqtKHBtVyg+Cd9YlZqPw+sEx2elEdwRVNVT4N6wk=; b=Gxeh8t9SikI1Mq11KBvKw76Om5qOdzGfIoltkKpAUl4vymSeUkeUy3KcgEcVZONd0o ijkR7PG61Z3sSrP7FjFfnMxlSJnkX2ePVH7AQ/YnoJZk/wJ0+/kOSMWT9ggracNjb5eN 9/0yGwRSVDsvyu6XWfUmnQrNW51C2xDY45mYkllYGl1OMVGJ7vYfJHzRFZWVscJ9AByi mKkgeGOShggi0VSnfUbEIE/7BE1SnYI2G1ygiW4yJikjYAJj7oYP7/9G9zUwSBqTezyO YubAzVgBcAKx9ORYgcSg6yQUbIJ6DHYMTz3+erxAwxF2kyTXRzbjI6VOswRPo9JyTyB4 FZig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692212909; x=1692817709; 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=oW5kqtKHBtVyg+Cd9YlZqPw+sEx2elEdwRVNVT4N6wk=; b=abpAW36xFEHdKIpdjns6VEzgqjdt6NF7+jF56AalfhAvfushOo3q/0PloYLFaSG0j2 ODU/IQS5v/CLMI/l68wMVIis6+sl4GALUaTuJjW61evEAK5hgcJJLuhPM789eBHHHtZZ gCrt+VXYSwZBYQdl0Xm8t9QA8V+CS+UcWGleSAJImpOthOVHr2N/UX+36eAaeQPx3NTB DX0bJRblYrGYeKcq+G0pE1jbOWfgWabZ6ayoP9W/2sc/BVfN3Z1wloxS24G/Gf+U9Fk9 yJ0fnE6W3lpCbNxMngUdsQMngSdFa5P4mP3E58t+e05HPurJIhoIubevO6eCPGq62J5Q I/tQ== X-Gm-Message-State: AOJu0YwE36tWqaWjmIfkokZkMzhhPZeC6Yi+BWk0JQiJJ+TVcW9kNi5s 4+ZlRsNXbaojoItIWiOr03w= X-Google-Smtp-Source: AGHT+IFMRgjqD6qS9RDkcPNKp+sp42EgRrn2cqRuywDmeHhg+7JiW8v5/V0EJlDvSLbC2qPcJRPEOw== X-Received: by 2002:a17:90a:cc01:b0:263:f5fa:cf1b with SMTP id b1-20020a17090acc0100b00263f5facf1bmr2161321pju.30.1692212908713; Wed, 16 Aug 2023 12:08:28 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:93bd]) by smtp.gmail.com with ESMTPSA id z2-20020a17090a1fc200b0026b46ad94c9sm90263pjz.24.2023.08.16.12.08.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Aug 2023 12:08:28 -0700 (PDT) Date: Wed, 16 Aug 2023 09:08:26 -1000 From: Tejun Heo To: Shakeel Butt Cc: Yosry Ahmed , 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 Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 3AC7E40031 X-Rspam-User: X-Stat-Signature: 5yetzsashoqpunkrnk86dkcy4jcyzq7f X-Rspamd-Server: rspam01 X-HE-Tag: 1692212909-98892 X-HE-Meta: U2FsdGVkX1/p1K0WJ0Q5GujkMNGocVSyzcQy6CLhUDuUocgT1m7lpO+/JgRB2HPqX9P7X+q3Zay+1GDOI/2FWFgv9+SRiQbw/DOb6Df1BuQKlEjzOw0Y5X6BjU0Zq7UsO82tS29o4E30iDixuClDNbw9OHPhDL/UGM35GJC+YyvMCvJWH8lIChG0QHjeNzB8bhJpgy1s1g96elL1GgZQdcVA/yZ4P/qkYl3zYIdHq4V5ahY7K9dmyMZmL9aIu3c4Qin3No/joIcKvjjUM3/Ps6+52KAlFx/c1AMHY6EOxYkwH3miASqwJjEeBWDLQvKSnBJDw1SJhXwrOY/RLk3eOWg/wco5yihuy8rdFiS/Ao+EejC8vEfejYi7L0PX13WMUujGPIFCBA8ZXtnCSLGoYPDe6g7ZLlJnC7rhjUZc7cftMRR/uIZhLYjzDU0STb3mg9/4fRP3o9U9sH4TTxq/WZvv0eCpNUMRfSu5+Hi7EJXupf+wR3ELIg6R2Z2QLK3F7QNBTVjNy68ZaLh+KVXT0Efb/EszfMZb7W2Dx3f/tXjRXp8POvaA4obc7zJoQ6CmkAM4beOdbIh9uH38zCFck19ZRNZ4w9xD522SkBsVAXTHIoqCdl7oHjJ50A67AXzYOtEOHq/YcmiTtUEQnK1rVv9mUZpZQZUFOsNvdvTcqvJFRqnQa0h8RHZOtC9ak32duf0h/KGJ2ySZCG2rjfO0vnVHtGAdl47BMzNWfhZbBdmdbdc35eltoqkMEMzhEJRnQmqYFUL1Ij56sibMi/xInxqXLtbyROVhXTCRe0X0FvKHSyT3oJ4u2EV+jVSW/mx2c3KMgThKitq/IJlGlviyypDbbsdYWeFU584qFcD/NeljRonX+ZzPP6fy9QT73cLXSkEI7Xiuf3c6UbzoVUYX3cZBa756UBjkjCNNgrvL+7PvuhGEZ4hMjUDRE3vS7kxBBAwe4z/6BZTWE17n4N5 9VNkfay6 /D2xM3dLy52xSu6HKPaarrBJSOTVB2TOhcC520AQsWAPxMDMuZaw8adUM6aVAXAVtAccRjvLh/ybgvh7ffnNlxW9rw8w4hbNh+q8pBV5BJhRKsnNPzhR04jTPMR2qjKJOon4ssFr8/IDDtbE7LH56Ab6lGeQTnzUvGwZljrIUybqTEBeJckxolpHnvOiMz4WM7JvyfuoV4lC3aPGkzUS83pINm1pL8RMksMw/QZRKNU5AsN3FR8JV8xa13wTiTxatZ/TazQKJencPRl8xLOgU2cUDBtZlsUGD1uMAex9FaXWnPAawYUzqtK1XcWPCN4GaLjmHr7GB4WScQMXTBX+nB0AblcG2CvGsrd6VulEOQ17m95Y7hn7k5GBnSaS0yuf9/Ps1+4KtFPgyVOpLLKr1NG5LYoKNE4w8YlcKgMttoFDJ1sR/IDBUi5rhLz3zfTqJKmmcMWaJLZaedzFRYWMmpxO1lAHTjto6XdN+ 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 Wed, Aug 16, 2023 at 10:11:20AM -0700, Shakeel Butt wrote: > These options are not white and black and there can be something in > between but let me be very clear on what I don't want and would NACK. I'm not a big fan of interfaces with hidden states. What you're proposing isn't strictly that but it's still a bit nasty. So, if we can get by without doing that, that'd be great. > I don't want a global sleepable lock which can be taken by potentially > any application running on the system. We have seen similar global > locks causing isolation and priority inversion issues in production. > So, not another lock which needs to be taken under extreme condition > (reading stats under OOM) by a high priority task (node controller) > and might be held by a low priority task. Yeah, this is a real concern. Those priority inversions do occur and can be serious but causing serious problems under memory pressure usually requires involving memory allocations and IOs. Here, it's just all CPU. So, at least in OOM conditions, this shouldn't be in the way (the system wouldn't have anything else to do anyway). It is true that this still can lead to priority through CPU competition tho. However, that problem isn't necessarily solved by what you're suggesting either unless you want to restrict explicit flushing based on permissions which is another can of worms. My preference is not exposing this in user interface. This is mostly arising from internal implementation details and isn't what users necessarily care about. There are many things we can do on the kernel side to make trade-offs among overhead, staleness and priority inversions. If we make this an explicit userland interface behavior, we get locked into that semantics which we'll likely regret in some future. Thanks. -- tejun