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 75D2FC369AB for ; Mon, 21 Apr 2025 17:28:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A01B6B0008; Mon, 21 Apr 2025 13:28:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 650BB6B000A; Mon, 21 Apr 2025 13:28:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5197F6B000C; Mon, 21 Apr 2025 13:28:58 -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 329266B0008 for ; Mon, 21 Apr 2025 13:28:58 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5E15D140A29 for ; Mon, 21 Apr 2025 17:28:58 +0000 (UTC) X-FDA: 83358736356.25.E9C8241 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf05.hostedemail.com (Postfix) with ESMTP id 7395510000B for ; Mon, 21 Apr 2025 17:28:56 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FwPg2vh6; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745256536; h=from:from: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=vG4L1oHMagTDUnGqJG8Pj6sUOyHcw1R8xhgw+ZpiQQY=; b=VAZUkuEm2cmrecsvM/v1R4i/38Jto8FrtjPjoUNTlNGcNLDVDD3jWvcC4LUM/vgWQ/1Ak+ 9zwsRKrMeYeg7Olr6tey9QXNflo9q7E4oX5giNsIIt/ydAz73x37zRRJ4y4HTLy6+AWmYm hUw0/i0U4ax5lwUKcX2Gwsj6zG5tXQo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FwPg2vh6; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745256536; a=rsa-sha256; cv=none; b=Nqf1CemMX5BlIB5WToIRGnMdpVz189Vw32vZSgqV69uFtMkdSdMsbCsOgJKYfOOBTTOkFr 79CybJK1Rdd52VwqhXFVQFjOhS2j8OfXou7rYt4LkWdLrugHuTM66Lp8x0CPEVNxHz/71F bPfHvEeJzgmeiCNyUuvKephPI7nQmug= Date: Mon, 21 Apr 2025 10:28:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1745256533; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vG4L1oHMagTDUnGqJG8Pj6sUOyHcw1R8xhgw+ZpiQQY=; b=FwPg2vh6/QXx0x8p+cDPsZYRgoRp1GzFG2qd3JJhdgVc9j7aSpDrd5zJK0XaX2J2clVX3y M1uyNlT7F+0yQB7zwvi5uMMFjXBgbiMkg2FD5mmQqU7V74glo+wAq8fCummrAPBl0qjCI4 UBYbWpJ5L9Bh23t8rPnLug1cw8Mod8o= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Greg Thelen Cc: Tejun Heo , Roman Gushchin , Andrew Morton , Johannes Weiner , Michal Hocko , Muchun Song , Yosry Ahmed , Michal =?utf-8?Q?Koutn=C3=BD?= , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH] memcg: introduce non-blocking limit setting interfaces Message-ID: References: <20250418195956.64824-1-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7395510000B X-Stat-Signature: s18mztfc1y8yqab1mggjjk9qswsmdapo X-HE-Tag: 1745256536-427222 X-HE-Meta: U2FsdGVkX18ueaG/6T1Ai4dUVuZ9OcRDy/7uzdyD4gMTv72oTBd8TlNuzDFyIqZ9RuEObqYMZ/CWEUTtZRFkgWyhl4f22uxIDcr+ncYCGIvG5jignN9h8dub2ArQOuLl53L4w84fnajaGJ9GFVbUs4n3bMvBkiWujJFryGHrW7ZxFxQ7fqT15gVqp7rgJQ4m7oz6Jbk7+35iASTGM6jXpY6OI7RAb/57Txe/CZibG1oBBPO0b6oHb7PK4tjMTLO7Ex4HKh+O/hvoXyNb9+7dnaZQ7BeJMy3T0DQ0V7rAZI6xoyIg9kCAr8FvNAoZDulhUf/cMUe9hZFnxUPADkNrKplpW7njS/l/uNNRcyUwDMGcz8doxDRsiKPfn4z1zf7vhu/3hP+wwXF4TxmkGHr4DMPIgAXzaMPGtPDXChMRv5K469lSA9ZEH/RzqLDbITPuqET3uCMgNA0sdWcOLB5M9o3e9kQJWPlQ4XFXqF/KDkTVWgtiddL/3cxs/DmKxniy30b66V0OPVLQ9IIt8L/RwULFt4qfi/NnJfbGlPg3pu8kyhbfYae/DavAzNTUu2FGbkP88h8DI3OCzSKhPGd+opWLbaeTWBFU+8WSMl+EMjCO6/A+34F2l9XrHbZmcJijQM++xkkBOs5IeMShxqW5dmwVoR3jnbhhhK9oVI2XxecAdJOkWXbAiAi2VRaO889Er+CTAY50QXjhYr6GRFXbrae1n/Z0BMJFHQm1P4Qz1jNsbtzwKHwYdSV4oXBV3GGAaga51OmIYD0AZQNd1EnyNaAAO2BfLB30B13qphHyRbzSSDVBXC+rEwEExU8MCnVYNyBULKWdgT33jrP8fMVWYBXBO2rVWnQBP1mWT6i/9cv6juqhKTGEZkATAFbQQkh7iFvojsd1skbBhWTlUpMVA61WOOnyaXnMGCcridPcm847BPzmxxmzPh6BOc57bG5f6gdea73/Hi87R0LwEUv 8k2q7MCo 7F+6jJmpcKkn6KdQVY97JuC2aIRRkijEiNGtfvDLjDEFwNuwR/4+xm+dzeRLsx5DN69rrqWMqj02ajQrRFRjhzJYCZF5saxlaDk0oYYMvBMTXXJalL9ri/JnR4+7J9j9iiz17zPB2QfHNiPpGNaL3NqPUkAubNTIzIDzuNFynp+YiE14LW6VxXarlhg== 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: List-Subscribe: List-Unsubscribe: On Mon, Apr 21, 2025 at 10:06:13AM -0700, Greg Thelen wrote: > Shakeel Butt wrote: > > > On Fri, Apr 18, 2025 at 05:15:38PM -1000, Tejun Heo wrote: > > > On Fri, Apr 18, 2025 at 04:08:42PM -0700, Shakeel Butt wrote: > > > > Any reasons to prefer one over the other? To me having separate > > > > files/interfaces seem more clean and are more script friendly. Also > > > > let's see what others have to say or prefer. > > > > I kinda like O_NONBLOCK. The subtlety level of the interface seems > > > to match > > > that of the implemented behavior. > > > > Ok, it seems like more people prefer O_NONBLOCK, so be it. I will send > > v2 soon. > > > Also I would request to backport to stable kernels. Let me know if > > anyone have concerns. > > I don't feel strongly, but I thought LTS was generally intended for bug > fixes. So I assume that this new O_NONBLOCK support would not be LTS > worthy. > I got the request asking for this behavior for distributions on older LTS kernels and I think it is solving a real user pain, so worth backporting to stable kernels.