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 4CAC5C282EC for ; Sat, 15 Mar 2025 00:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8AB6280004; Fri, 14 Mar 2025 20:34:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B392A280002; Fri, 14 Mar 2025 20:34:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B449280004; Fri, 14 Mar 2025 20:34:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7A0C1280002 for ; Fri, 14 Mar 2025 20:34:22 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BA2A21CC7D1 for ; Sat, 15 Mar 2025 00:34:23 +0000 (UTC) X-FDA: 83221914006.03.D6EF162 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by imf22.hostedemail.com (Postfix) with ESMTP id C63A3C000B for ; Sat, 15 Mar 2025 00:34:21 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WshahiWv; spf=pass (imf22.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.48 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=1741998861; 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=xGLTlaUNAQGNRgFcp7B7w74lXcxE7FcMiChs3RZNW/k=; b=7ztQ2ob98GxiM+YJTQyEVK9yFUq0jXmEA/HDfC6SMm8ziIGNkL50QvNPDnkKlDctIaC/GQ 9Tr9iZiAM0rZS1hlI3GC4qj7jbeOkDbnCao1SySY63tSOFdW+MF22XaZZQ7H30gRnDe9yb pCSn/IacXz0WNjmz8/5BFS4f7Ajoy/Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741998861; a=rsa-sha256; cv=none; b=ZHqoSfTt7cIgCvjsAFnWszeOsWUPp3EELY2RC66XaAW3eTMNTIF3Fy1FfbR4oEIJU3Ezja yMV0+LD7pfJlS6qaIef10WjgTtIoydZA2HRjhBhM20M7RVyxls+IxaAYmSacdeNIO5FOgS AG8iHhZFY6Ddc1LUkL/FihlLhHD08fI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WshahiWv; spf=pass (imf22.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-390e3b3d3f4so1561887f8f.2 for ; Fri, 14 Mar 2025 17:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741998860; x=1742603660; 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=xGLTlaUNAQGNRgFcp7B7w74lXcxE7FcMiChs3RZNW/k=; b=WshahiWvCNIsNL9dRehz75PUVQTjru9OPS1iD7OJTjRq1ujd0VPDJDcOwbfKtAURjU qg0pnHZpPcP1A8tnI5YxqE0cZXT20++Hm+oBaiaXTPZ5mXKeUFYBfsL5Xerx+aKICAZV JWCZnqOgy2NEvsJHTKkk6t1JTYI65xoqpS19+E3Ng225Iv+PHGBeFyvfsHsO3s58y4w0 eAwbCzCrPle+YBrPHpBodqfCuNdrb3rDbe5cqpeYcMyBdtREU8NB3vTMH0DArQ3YdvpY Kk1YUhNM0jm4ugYe2oZEjQhSE3+M/imST4kkYOwp9aAMKtjcnKLvttVpL/BVfC5M5RDj CTkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741998860; x=1742603660; 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=xGLTlaUNAQGNRgFcp7B7w74lXcxE7FcMiChs3RZNW/k=; b=fGnlfbb1vMlzUpXm0Xxc8Hb+zm2eMzLo1hGU1V+/XJ+W7K6F9w+OymTX7zXaTh5gf9 NK+xyHqDdtP6fqBtJT/SEVjakEIZTezojS2gzpy1eJpLO4AkChpS1ymDl8Pn3a3L2Zcr j7D9OW8gI1xuZKHHAI7uiwcFhe0Gb1cEeBhUnJwE8z2GlTJ6oDMlDDc8p7fLwWyeDHa5 /xb13jhnWC7b9wbzcSExJ8Sz/Yjazf6SWw69EwGchW5Y2gCd566nwNFvlL0IO5TO+dGC JWS4yHKr9nipyVL+DzLLGvvqhGbAnrqbbUtLvqo7jNSO+e7vrOMzD88FdLMTpStUUfa6 a0GQ== X-Forwarded-Encrypted: i=1; AJvYcCV2IsXekXqnKeuk/Yptl224m9DjmoKx7OnkEd5vu5FwAnR7IcujsGyqBfN8vnK1sCdI7f7tvozvzA==@kvack.org X-Gm-Message-State: AOJu0YwSwnuzKcmebmaerxV7pYyQSsjSFZ87PiqxY9b+YIjwg9kQwsfZ w+Unc+kM8XQy1AAo2gDFPztpRU3AW9tKhY8vwtp6juZDhFSiSeFcijD33+XcyItIIlboumBvN1T HB2LB5eR4+fOgVdkaKh+phbUgxrA= X-Gm-Gg: ASbGncvyB1oXvSRPp48exSdOhpImJCrs9BCqKBn43BMGLlSPVOYnClNbrXZyeToUJn4 Gfjz1Uxd+PWfu/epOi9CH1LnaEAMwKVTFMe7QH8GFuqCBnsSbEkKZ42HnFj7JDQIiFniUU4aPoK m5rAhkeBd1otVRoprZ/ro2YeCkZVn3/K5UGjgdxxDLtg== X-Google-Smtp-Source: AGHT+IFsW4WwR/5hLucAOv60jvN7cIlIU5EYY9RLmRUSbV0nGZaDBUl96EggwZ7aPaaWgn0kBmhU7AzjYy8x8NJs88k= X-Received: by 2002:a05:6000:1884:b0:391:31c8:ba6b with SMTP id ffacd0b85a97d-3971d03d345mr5580362f8f.10.1741998859888; Fri, 14 Mar 2025 17:34:19 -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> In-Reply-To: From: Alexei Starovoitov Date: Fri, 14 Mar 2025 17:34:08 -0700 X-Gm-Features: AQ5f1JrNWO3fSZJO1zPwFJbgMywZJwL6VfHigqxS-tSZP78BuN9thxzpBtBiIhE Message-ID: Subject: Re: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation To: Mateusz Guzik Cc: Andrew Morton , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Peter Zijlstra , Vlastimil Babka , 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: rspam02 X-Rspamd-Queue-Id: C63A3C000B X-Stat-Signature: 4hmtgbo1z7c1orc4i8s4t69dzd3x1ehe X-HE-Tag: 1741998861-391675 X-HE-Meta: U2FsdGVkX18XLZAXM3h6XVxmgsXUyUtmPagbu3qh5IRiqiht8dRPgdZH5smpOCHw5zVXDs0C9U2BUumxpyRb+Sj+U+czUGOCp+STqLpH5sEQSRFU5RIrr+RSPumnLmyc1qH9EXM45oJouaXobM2Acu8XK/ujiGGXZg0p3n5E+d0qfa/FIJJI5QbzsWFQBbU2y5Rg5bXfEoxGzfvF60qKhZYToKAWOvu3HdjFmPtb5lPfWvnCTKTjx2BxgBJ28lt5uWcZsKfK7or4IdG8/TrJlSktUEckckH0+m3now0vAJckIMRdvhhpBMMK+JtiSr3MjKmTQKJAz89zvkkmeNJ2xUTqAmp0TrItRLPHhl/r7N2GaZkOHi3Jbc3Jf4ANnMachiw+kadhbHlz4NSkeiuE9eu84IkDMdUiui/LA5sGbGvwXbIAgd90X4J2OFo96ExzFvf1V2sgGp4veQTMeS3mlwr+7SfKE5t9oK/BOjBeuz9Q+A6oPPbvWQmLp92X5g4L5FgmgDC7ovGSHLLob1r9nP02+c33LqgtfBh7olTTRWFoS909wgLmy98AGi0KtNbcVET3eS4h2FF47kV1nWs9GakADRE4soK7AIrDQyekRBrcRJe7YfTrE8/50sjGPURc2wTsk01giPOvTgoTOsrt9qWliXL01e1yNy3PmLNBbGR158Rc/Y9nZVvb0VJZm2s4vziAlkZocMXsw2J85TdDuQeMYP48lPxVqj7lVzsg79tc45aDIglss8X3/5P4bqGiGWNtmc2jHr6mJug3n5HkSvTRcDd0TEIBmR6+pGw/G/r0GquFPAzJifZnCVCijW+yHZqLN0vxzmilfbdmMJzcrZfCFpsjAFZ21oudOAR6vlZZOgi/SM+zZ7m2efzMTqT6ee95rsdkI8MeHyfbq9SAXLoKx3Jtq8aOB2DHygVVsn5BVCiPlnU7DCQiMV3Vn7G7Rfl2F746tOD6hZQ5WxC 63ruEjoO 1ST+hMIx8s+xQyHiTLBwHD5y6FQYj8cLqEESLSdPjkWaG65aa1gWJVQgpsEX7ePJrZR0cVAO2r7CIOfKMbfxiWr81kJqEDif5Yso2kGI1de2/YLVaejXmFcN24r6E0Yy0nvrCYDtNdAXJJ64VoYxWpx4mkTuLEtnQxVF/ZhNQ4H7UVXPdwHAsAl6iPhDPeHt1FVoYgDiqtcnkp25+jciWNXvKHMpYlYZfFSqt5G0qzVg2D3kxJu0Y1uGCDjoy60vN10CZgYaeoC2wRJGdBu+jIz06c2nTnVcbOzqsP9hTNYWPAlkJHuv0tyzJDOn4j/r54lMMuDSBh+PGMWhRMn+C88RTv1lNHroYoAg9oy0W/QruwOkiPlJZqb7CegraC5ewPr6ypxk3SW33Y2KZ8ndW/Gbe/AdCoeyolKLV7HLvqpeqvcs6nH3XY4MyodvAcMZVr22uDYSSYDZ9CksutOnYgGwootwCoN3HklyT 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 Tue, Mar 11, 2025 at 11:04=E2=80=AFAM Mateusz Guzik = wrote: > > On Tue, Mar 11, 2025 at 02:32:24PM +0100, 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? > > > > I have some related questions below. Note I'm a bystander, not claiming > to have any (N)ACK power. > > A small bit before that: > if (!spin_trylock_irqsave(&zone->lock, flags)) { > if (unlikely(alloc_flags & ALLOC_TRYLOCK)) > return NULL; > spin_lock_irqsave(&zone->lock, flags); > } > > This is going to perform worse when contested due to an extra access to > the lock. I presume it was done this way to avoid suffering another > branch, with the assumption the trylock is normally going to succeed. Steven already explained that extra trylock is a noise from performance pov= . Also notice that it's indeed not written as if (unlikely(alloc_flags & ALLOC_TRYLOCK)) spin_trylock_irqsave(...); else spin_lock_irqsave(...); because this way it will suffer an extra branch. Even with this extra branch it would have been in the noise considering all the prior branches rmqueue*() does. With unconditional trylock first the performance noise is even less noticeable. > I think it would help to outline why these are doing any memory > allocation from something like NMI to begin with. Perhaps you could have > carved out a very small piece of memory as a reserve just for that? It > would be refilled as needed from process context. It's not about NMI. It's about an unknown context. bpf and other subsystems will not be calling it from NMI on purpose. It can happen by accident. See netpoll_send_udp(). It's using alloc_skb(GFP_ATOMIC) which is the same as GFP_WISH_ME_LUCK. netpoll is called from an arbitrary context where accessing slab is not ok. > If non-task memory allocs got beaten to the curb, or at least got heavily > limited, then a small allocator just for that purpose would do the > trick and the two variants would likely be simpler than one thing which > supports everyone. Try diff stat of this patch vs diff of bpf_mem_alloc and other hacks to see what it takes to build "small allocator". Also notice how "small allocator" doesn't work for netpoll. It needs an skb in an unknown context and currently pretends that GFP_ATOMIC isn't going to crash. Any context kmalloc will finally fix it.