From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH] mm: memcg: provide accurate stats for userspace reads Date: Wed, 16 Aug 2023 09:08:26 -1000 Message-ID: References: Mime-Version: 1.0 Return-path: 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== Sender: Tejun Heo Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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