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 9C309C282EC for ; Sat, 15 Mar 2025 00:51:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E875280004; Fri, 14 Mar 2025 20:51:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 595A0280002; Fri, 14 Mar 2025 20:51:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41199280004; Fri, 14 Mar 2025 20:51:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 21569280002 for ; Fri, 14 Mar 2025 20:51:21 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1DAB21A0709 for ; Sat, 15 Mar 2025 00:51:21 +0000 (UTC) X-FDA: 83221956762.15.836D24B Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 232A3120008 for ; Sat, 15 Mar 2025 00:51:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jeFwaTDz; spf=pass (imf29.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741999879; 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=cfrltfsopWOEkDdkjziSnRiumJrMPq0vZWhc3RqItwo=; b=WA3ZUfh2Ya79fWLRnd/X6+oSSN4eVnE3qzHR/9Nc8+aQCR/MggGLkTkUvItQsdAG2Yt/5f 1jPFBEW3wfJ349Qxutr5P2O5nFjF+fE6RlwB1c8ze3oD8ophWGiTRL8Vpla0AzBDb8aQfI Xj86FYx9MWlzzuB3+vtaSKTx3j7Was8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741999879; a=rsa-sha256; cv=none; b=KjoHFoA7Q+6mwS5ZYZ3sc69ie0/BBjLMbCPgfH62Z9ib8UkFyGOmBgD3/aqb1GuzHfiIP4 RQ9T5+LV7jyZhnVKUlD4Ga2qGTe5ohKS3rmIES5T+9fWl0CP7k5Yum3UrPRyERHZr+PE3T lVj1P8yyJMriAdrbPdPYkFqIxQnaqWc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jeFwaTDz; spf=pass (imf29.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-390e3b3d3f4so1566475f8f.2 for ; Fri, 14 Mar 2025 17:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741999877; x=1742604677; 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=cfrltfsopWOEkDdkjziSnRiumJrMPq0vZWhc3RqItwo=; b=jeFwaTDzMreV6SqF3qJ1WCr78leQOMxB9++aBlKKW/kS9oGrf9NxrM/O7CSDFYUrOT ITbvMdyRYncgKDeUGAdetTBTy6jk1K4Pdb4KN8h/qzuI8XOM42+zDaFGy+lyW/HBSD+l 4KdIJgKUVyZ8RIGfjbo8Jzns6Kp7ye7LldR1yEyDhGZWIZjg+x67l1abLpB+4oWqIAMm 5P/CdutwlUas3TrR2BtvK/6HYV+Y0ei8kXYNXH9JbBnnSCOAO2TS3G0HOH0aDxOUG1mD KrO0FKwdFk1dZgYChHFayN4iwx+xtRrdFhQ9Ef+67JVtmB8zhSs8AWyFaDxOxDgJtOhi OUDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741999877; x=1742604677; 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=cfrltfsopWOEkDdkjziSnRiumJrMPq0vZWhc3RqItwo=; b=e3sSSoE8MFQeB7V1+nVUPF8H6hQj+bpXYzAUzlTF/eKpub+5UaOYiWPKqhgfGT4X77 9i4qdrWXVwfgMQvhnPYcRLwC2Tt/CnlJAiaeic8Wenhi9121Z3Z8JZlgL2WTyOn+hVR3 6DVQMMCI3gGJj2CsnQ9mrj0z5L57bguZcDSM/m+G6JiGLl61DknU1KybHbzKjIZZ3WE0 C9+tgzTZhQSZE8+Yz9iVEU3hcV/ys+EXMdyn3yzmKWBLYGS53XhMR9aVD8YkyEapR2Qb EqOjRCSQkkS8EwaJbgBo6AhgG0+44KQDsyJ+FWF3wr6tnDYexFMGGroRY5pQQ1qeJy8D Segw== X-Forwarded-Encrypted: i=1; AJvYcCVrQKIOttou87KiDX883Lvp9zBfjvSHBTSVZlWuGjP19J6j34Vd/2DGeYboWAPpGR5RFvk2Sr/CBg==@kvack.org X-Gm-Message-State: AOJu0YxXTwJ5/dvShuhBelT7y+HhLao0T0MhWGWn1jqSn5M/4dK8+5j5 swk5pihgSvQglI4sGbDaYbv49+pJbVGR8RztRc14aAuXJzClZ+NZcTk5njvYXg6K+VE2+o/EHhH +h8HshHcCUlZbc6PYmAUUYDsAc50= X-Gm-Gg: ASbGncsLh2qMm6AMFU8rtBB3BCwTU68lh7x/JmGI/p0MQSkrdIGipkmnMNMRWSMOW28 Kyyq/9ElqoDEfp/5TlG0CMjIvjnnkXdDrW4kS2pXwquY4FOz/by8M1w4b6c74t+tsENqcCCnQa6 zcMPjKdduArrD/pgOCR2xsw8PJZWUh7yMK1c1Swv9tkg== X-Google-Smtp-Source: AGHT+IFS3nOsiYjzKrdQuDRfcPwmywgny0tg84IsYCcaHKUdTlTlGBczedIn8pKY0TIKQ+/ZOfpsJ9aKkUPW2YTQdwU= X-Received: by 2002:a05:6000:4012:b0:391:4bfd:6de with SMTP id ffacd0b85a97d-3971ffb3a4amr5885661f8f.46.1741999877524; Fri, 14 Mar 2025 17:51:17 -0700 (PDT) MIME-Version: 1.0 References: <20250222024427.30294-1-alexei.starovoitov@gmail.com> <20250222024427.30294-3-alexei.starovoitov@gmail.com> <20250310190427.32ce3ba9adb3771198fe2a5c@linux-foundation.org> <4d75c5a8-a538-4d7d-aaf4-8ecf1d1be6b9@suse.cz> In-Reply-To: <4d75c5a8-a538-4d7d-aaf4-8ecf1d1be6b9@suse.cz> From: Alexei Starovoitov Date: Fri, 14 Mar 2025 17:51:06 -0700 X-Gm-Features: AQ5f1Jo6apmq0POZDPJ9QQGxvg-t4s6RoF24DdcgRda3D2gW12kCapbDmnMKnoQ Message-ID: Subject: Re: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation To: Vlastimil Babka Cc: Andrew Morton , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Shakeel Butt , Michal Hocko , 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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 232A3120008 X-Stat-Signature: k4pfkk91aqmhwhjskpfxmpmmkowf5tb7 X-HE-Tag: 1741999878-462360 X-HE-Meta: U2FsdGVkX19lRk2GU/CUyM6hIug7VN+fIdGNGhoK6pReL4W9nw6Vcu7TFdiJ487djFFbf689IEABdo1rLG5c/i1Tv9KHAwP4fdC7QyRyoN/tl+yxkHo01c2Xg0pAhYr1uSFyePfzqq4vviuKTia6YNx9cevhV/0o+0FdHCXnHbuxZkTHIayn8pJgnqFe3pN1bzKe7Nss/doqCRms+FoHJGEml0ZdUXUNnHqZkftu/5htqlDrc8wR1tep0Fj3Tzqn19Zah94eR5Rrmb9i6D7vu28NtqTa1vY62z4vxVOHAxOcxnhsSjCmpksC0fLkafIFLXH4BXWqHpzTwMNPIzNbUbqJ+Ef3fVVlKsVbRTvZLC9emal0ek37/DTnKaiq2Ecj+SzZIddX2GnzO/Se+3mCdOGgAVpUysNJ1IxevNB8tsdh4EeFn97xFel7XtTlXC9yDikEZHRJPJURAqDzvNy0yv55IQQbbVia7j4qj7KSEfQL8qXU6MHRzBr/e3y52DEUy1DrZi/ef7p8NKFT3AuI4VN4JGI3ZBQnLygafbHFBgRs0yUE+z5m7JXGgYFZxEhW2/ioLlgv76gzXEKHP7xBQ6TxljWLqhily8BD0qTdOsz3sjkm9QnPX110Vr+otvqMPYqczaOFFQ/0HAbcDpjtTCOULtfowvKLLEeJfq/7r/aK2pvwDz1AoeUKgUcVcz1BMkhmnSSLxVxMUxEVGqiY4/MPF0eyiQEbXtn1iPxaLg37W56PAdpE+rICi9/mJPVDmOB+MaFWp23Cr6EH43iVw3dM26EfrJIwmCffvjwd9Fs2sDstAg/v7o5RKFK+DeKaGES015fLn6Yvcb5lIOsE+xlCEpK9VZi5hx3H5Q4xvlKgtdO6kj8dCOh2ubhSDpbh3cCwbn0gmBLXRENt0g7VW2CJcfEdQEK6vTaIPyP0Tg+BY/THQk/3sH1nWMGVmf25gDw7G6hyF6wuzGg3LE8 h9hkUvCl ogYi1QRMOSZPZNGAL7IIyrsNsmg4TYVcPhvFnXY7wHOQFYIRZ2E/v/hDBmLe0G3qOLCA9JtDcY86IPQzPvUBZ2qHpy+KjHNkVrP1dAiiNiY6ronJfw6VK3RyRYqMu81ERgDwYs/XTZx2sBnBe229abK1Fs0VRBFGu6QrrBUr1+44PZswHzwxSw3Xs3dNvrmps7LZD91/PH8VUiG4/CRD/p2PYYei8X+zVtab55A34BzgkqZSrOHZxh9aYl7gewqsAK/ccXIYjVF08nL95zcKYCumaQa+7rhLlfimbY2UzxJAYrrPFl9nzxtyNE06olQkqt6y3bOsO1xBWrNTYEdlFB8pMw++kAlFTefLEXN3W4xemRIVtkqatv9dL8Q96wF7u1E3BMMz//wnDEQsEAPrX/e32vYfCGxEfKeSDmB0+MkXUGms7i0nHmQPJwW47lEoDooXKzLGowaKec4msI8rUSFY8u67yOKFdu1Yxx2pdx6IBuOw/TZ7+cZPNbcPlmljS2LUxRlo01+ryYNaaBa8lsw3TbitbxVmi8d/x 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 Wed, Mar 12, 2025 at 3:00=E2=80=AFAM Vlastimil Babka wr= ote: > > On 3/11/25 14:32, Alexei Starovoitov wrote: > > On Tue, Mar 11, 2025 at 3:04=E2=80=AFAM Andrew Morton wrote: > >> > >> On Fri, 21 Feb 2025 18:44:23 -0800 Alexei Starovoitov wrote: > >> > >> > Tracing BPF programs execute from tracepoints and kprobes where > >> > running context is unknown, but they need to request additional > >> > memory. The prior workarounds were using pre-allocated memory and > >> > BPF specific freelists to satisfy such allocation requests. > >> > >> The "prior workarounds" sound entirely appropriate. Because the > >> performance and maintainability of Linux's page allocator is about > >> 1,000,040 times more important than relieving BPF of having to carry a > >> "workaround". > > > > Please explain where performance and maintainability is affected? > > > > As far as motivation, if I recall correctly, you were present in > > the room when Vlastimil presented the next steps for SLUB at > > LSFMM back in May of last year. > > A link to memory refresher is in the commit log: > > https://lwn.net/Articles/974138/ > > > > Back then he talked about a bunch of reasons including better > > maintainability of the kernel overall, but what stood out to me > > as the main reason to use SLUB for bpf, objpool, mempool, > > and networking needs is prevention of memory waste. > > All these wrappers of slub pin memory that should be shared. > > bpf, objpool, mempools should be good citizens of the kernel > > instead of stealing the memory. That's the core job of the > > kernel. To share resources. Memory is one such resource. > > Yes. Although at that time I've envisioned there would still be some > reserved objects set aside for these purposes. The difference would be th= ey > would be under control of the allocator and not in multiple caches outsid= e > of it. Yes. Exactly. So far it looks like we don't have to add a pool of reserved objects. percpu caches are such reserve pools already. In the worst cast it will be one global reserve shared by everyone under mm control. shrinker may be an option too. All that complexity looks very unlikely at this point. I'm certainly more optimistic now than when we started on this path back in November :) > But if we can achieve the same without such reserved objects, I think it'= s > even better. Performance and maintainability doesn't need to necessarily > suffer. Maybe it can even improve in the process. E.g. if we build upon > patches 1+4 and swith memcg stock locking to the non-irqsave variant, we > should avoid some overhead there (something similar was tried there in th= e > past but reverted when making it RT compatible). Sounds like Shakeel is starting to experiment in this area which is great. Performance improvements in memcg are certainly very welcomed.