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 102D8E77188 for ; Thu, 19 Dec 2024 01:54:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CEA26B0082; Wed, 18 Dec 2024 20:54:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6572E6B0083; Wed, 18 Dec 2024 20:54:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D1006B0085; Wed, 18 Dec 2024 20:54:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2D6526B0082 for ; Wed, 18 Dec 2024 20:54:05 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8F55B141325 for ; Thu, 19 Dec 2024 01:54:04 +0000 (UTC) X-FDA: 82910037630.28.8A0272D Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf18.hostedemail.com (Postfix) with ESMTP id EFECF1C000F for ; Thu, 19 Dec 2024 01:53:47 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BNKSy4Gp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734573228; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=10XeDIZaJRKZ2vO6XMwcEnLLR+kxNMCc7bgQ1pNV0gQ=; b=ob0PSHxtgqID9Z0JYsMww+PydwZvGKYQwE2AFjHdaKSupcz6vrG00qG8vkfB+hxIPtI8QA vMZ7+M6XlveWe5aa2Vfvh7E/FK82sAl9KNAT69NKq+w591YrSt6e9puPKB12AHJ/9CVf8X nqPPdmUs1D6foz6VbkiVwiXKT1bvqEI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734573228; a=rsa-sha256; cv=none; b=4wZrXAYVyPQVahudc9l12h0xe9u8UAkTLXb6rkW2MBgVL3tTeveWQFcbMDTNuqO3UibeyA KbLkDjC0heu4r5G/pWiHVkGImA6Myj9v5/abnU1+po4rHPOPLkcoRpVRCfKbbbFK8fG3yx zVxXWUYyW9S5Rz4U8axMRpkeQ826wlY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BNKSy4Gp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3862d161947so131441f8f.3 for ; Wed, 18 Dec 2024 17:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734573241; x=1735178041; darn=kvack.org; 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=10XeDIZaJRKZ2vO6XMwcEnLLR+kxNMCc7bgQ1pNV0gQ=; b=BNKSy4GpGiMFG9uGhMYPEDdyL1DYA3gTVF8WZrii9QrsrW6zxGrojfjgEFTPx5mCm2 KwSiEwt2cZ9PqdRTJQi53E2KI9e0wefVoKLCHsDleNMzgro/xrG2kXG3/kbwE8L0HmiB 7NCxu8M5irj3k8+JY//YKYvxz68D1wsHZYe7ax5baBHN8vMDS+24fkeg/tK5HKoJ5mYD Y+TDX7FFaASZ5th9064BmM74a6x5sA8QqIohDNIj0EyatMZ4MrAQFhWPIqu0Wlr8OlcT dKEIgi+KV7xLRi5vdd9tMjEH7mo2XKRg73+0g5c5LgdzJfVhQUl+WmkRb4X3J+Fy49ts JW1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734573241; x=1735178041; 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=10XeDIZaJRKZ2vO6XMwcEnLLR+kxNMCc7bgQ1pNV0gQ=; b=YT4kHx+yKf3nughTkAUMkg1WO8WFofoy9jeeSsrQBthtIthPSqateWaelcON+dvRGO DKi7auCynY2xKiKtQvqUiWveD7XTIpFbZVeZVfN1me8tg7XGunWldpTSVBqHMXxplnqv JKrPs7eRLYJSc7eO7qfgQFVlCVhsEmk3sxNcu6gX0rYa+uUKZQQYr64woWuStj+RpwrI 4oGTG9WGZUPY4olEqTWaWbXe07a1XINUq7+M65rbEcbrhWUcryDLHmkAY72nuSRjJmlE rVHND5nuw/ulUTQOztnnp49uICwuhTfvEv2areq2wBh5hicy/qO+f1NE/7BOF54NoICr xO7g== X-Forwarded-Encrypted: i=1; AJvYcCX4lTzh9WoCHprodrU60bwU7umfQFFKDGFnkAshWDpil7tt5nerV0RHAoSlXlxVWy5JM4xSjgneOg==@kvack.org X-Gm-Message-State: AOJu0Yx78xvKxGU0TW66AWT88m9Bw+kNBEpQy6SS/0SQBA0CCLOcbAuh oAm6jykYauWy30duz2HxPyOKO7apXiFInSbCbY08R3vtJa+4R/31dQP8B/lLvFUlHflP5LLwFsm HFWRvJyV2P1kxZq7/ajOCMR0VTz0= X-Gm-Gg: ASbGncuZIOuWRAs7zJPEntdSJuMjRrxjv03WjIvHG2nx/aZ5blMSYDQlvwE4kNkT5xF Nxf11GYzuDOg6sa5A3zCkd3zdmaTngIDc8Z2tYA== X-Google-Smtp-Source: AGHT+IG+f2j+y3YOgHpx9wDxFrrsaRiwjUKBCYEbw+eq9iotxVmhsKe/xHF38k7skEGWq0fCX8lcnRM3c4wstSisGEA= X-Received: by 2002:a05:6000:18ac:b0:385:df19:cbf with SMTP id ffacd0b85a97d-388e4d794a7mr4682001f8f.28.1734573241070; Wed, 18 Dec 2024 17:54:01 -0800 (PST) MIME-Version: 1.0 References: <20241218030720.1602449-1-alexei.starovoitov@gmail.com> <20241218030720.1602449-5-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 18 Dec 2024 17:53:50 -0800 Message-ID: Subject: Re: [PATCH bpf-next v3 4/6] memcg: Use trylock to access memcg stock_lock. To: Michal Hocko Cc: bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Vlastimil Babka , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Shakeel Butt , Matthew Wilcox , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: far18rotrucqusjpdu6dr6rksow1139i X-Rspamd-Queue-Id: EFECF1C000F X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1734573227-687102 X-HE-Meta: U2FsdGVkX1/FsK0/UyFKtFvem69MaVH7BU65qnlXzr11YFT0NsAzZ44J1PjZ1b7twRpMC24CUshash7aHVDqDVdkurrXGkq/recLDOLq6YGwFzsb5Sq/R+ax92qxN/fPCdF2Ut0tGUY/hApzOuC5EAH83Cu2hc+UDjeT1T1q0CHam8dYeuEy8Qi4haGJHtwg2yMDESlDb4EO3QgmwYqbwp3ZYmxRGklMJ452NMLc7b9BGXAkNAaFZTLt1qnQNqE5li05ssGMoRv6/GqAbmQv78A5Ono1FfrrePlJ28ywfqEoQStZoWML9lEwrCCKq8Vj2a8OFHKtrySv/l7oIxtgaGkrrYtOtMqcCBwXBbSJ/p+E8OjWTOPWCRX8+sd6TiYGmIDJwYD5RWJaW8zSa9HLcNymovvA+Gc0ZoANeausX75mbj2GmNbPl8xZP8pkb6102ObusjZFE82wLeQBf8/tjguU3KSGPH7KdZJA5pySq2D2o/qHFD42Zs1nRw5WmvWCDscEFapAlaxRgFAcUro/EYPPfzJI0APSwQO8tYoxBWrPmCju8Tw8llVmHA4MPM4H0kjZSBjvIUcsRUkf+JFg3hRjhQHyapKleREaMuTcjwcpRSnG2bIHFrOg0KcsqUA2jnz6thZanU/9mOSal35KTb00tiOJdIjdCjO6TtKGb/Ly/SAmoxUcZl8/igdGrTNhNtJwKx9yeXtj+sKDzJ3b4C1RIy0R85/jmJuB1A15mI5iPqv+Yd4kd2aIslQo1AqcoHTADQOFKWcHqGnkB1cMhDaeeFs5UUcF0d1bkXcDtcy6oVojzawEbUsGKwTrqM+Y5DDFBR65r4PRyMo4RDrIUrQ4oK5cg7KSoCL7+3rh0TR6m09/+ZPccyonQgMmQTxdruekGmEpP0NcoHf9uugztfTmAGNbJ9kCGW/gHYgUn3omZWzRQHgrTSBPwsJU+t7UNou99L5o8Bn4tHHfTUt gA3yVFsX AoavyOe5nVBYvA30RSFDDVt27QKkgxavxfPJLAUHbgw6za0Fxq3VFkpp21XDYWRDTNn3go+aduLgTlGl6EPlP0I5G3JDArUkMmulAH0QsuptNMLF8OJJgmBU4qpDOsLxa6K7ekT0NX9dHPNvTMqsis0yhDKi0SCo29g7aiu+LhHWui7Vqp5ZTFKrcGXvLRDJ7oL659RQ4FoUZPqyJheAA0q+eTk1vAsm1a5eKhamLFAFFpw7XbBb1uk+QU7UFD8JVIQh8t1htQYFdPaDEHaffQ/HtfItH5SPJclk+U1i+MwNGsFpdwGXct6CRhuiHmcCRevCQdOzdTrmGtdoz3sKYWffzCtJhMkJFu/JD3+YV6r6WfFCNeSXbQzYgDNFy2XcfuD+dTUh4Q9uUhBEbaG0ewIBKH7Y2dr1e9CyfFGrxgpQryvs8mzhIELbUHlhj1gqz+yIa+8N5kqITsk3jn/nPdudt3aq4BeMZwLzL6pnyB8/wZ2Z8cE01oDrE9w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.012378, 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 Wed, Dec 18, 2024 at 3:32=E2=80=AFAM Michal Hocko wrot= e: > > On Tue 17-12-24 19:07:17, alexei.starovoitov@gmail.com wrote: > > From: Alexei Starovoitov > > > > Teach memcg to operate under trylock conditions when > > spinning locks cannot be used. > > Can we make this trylock unconditional? I hope I am not really missing > anything important but if the local_lock is just IRQ disabling on !RT. > For RT this is more involved but does it make sense to spin/sleep on the > cache if we can go ahead and charge directly to counters? I mean doesn't > this defeat the purpose of the cache in the first place? memcg folks please correct me. My understanding is that memcg_stock is a batching mechanism. Not really a cache. If we keep charging the counters directly the performance will suffer due to atomic operations and hierarchy walk. Hence I had to make sure consume_stock() is functioning as designed and fallback when unlucky. In !RT case the unlucky part can only happen in_nmi which should be very rare. In RT the unlucky part is in_hardirq or in_nmi, since spin_trylock doesn't really work in those conditions as Steven explained. Sebastian mentioned that he's working on removing preempt_disable() from tracepoints. That should help bpf greatly too.