Message ID | 20250222024427.30294-1-alexei.starovoitov@gmail.com (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 54AA7C021B5 for <linux-mm@archiver.kernel.org>; Sat, 22 Feb 2025 02:44:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE32D6B0082; Fri, 21 Feb 2025 21:44:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6BF66B0083; Fri, 21 Feb 2025 21:44:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E55E6B0085; Fri, 21 Feb 2025 21:44:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 778C46B0082 for <linux-mm@kvack.org>; Fri, 21 Feb 2025 21:44:35 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 010ED14114D for <linux-mm@kvack.org>; Sat, 22 Feb 2025 02:44:34 +0000 (UTC) X-FDA: 83146037310.01.FFBC1EE Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf13.hostedemail.com (Postfix) with ESMTP id 1A53720004 for <linux-mm@kvack.org>; Sat, 22 Feb 2025 02:44:32 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FjRBYG1V; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.216.54 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=1740192273; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=CIR+vaBmCH81gf3lPHKSq4yJjgf5dTcIauRXAOapdc4=; b=dJKpOnZYZOJzuktiMDB3jMbavbt28UzvXEAPNWeMarHAwM6e96gLMc5ST+8lfRsejQhuR6 8TsKRtL7pPkyK5GfnQmneyxztDAAUJb5mW1UJhej9dxgfsiMkoRr1880P4Ko1rkw6/zzxy xDAcQKYoMVmsPGtmjkthgs6xBMdVuo0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FjRBYG1V; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740192273; a=rsa-sha256; cv=none; b=VchKwr0SPDjBq9YESsTfR4bSIE/JnxC4mAnSqf0DOgyTsdI/BTE11RI83s1OcdZaQSx+ru /gYoYBLR13mWmIbEMD5JBKqM6pyz4KRq0eIMR30DPBZmjy0QGAE+zdgqqQnUubgKCVCbU/ Zpz2wLASzeaEvEVEVFkXTrLFQECaEig= Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2fc0026eb79so5620158a91.0 for <linux-mm@kvack.org>; Fri, 21 Feb 2025 18:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740192272; x=1740797072; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=CIR+vaBmCH81gf3lPHKSq4yJjgf5dTcIauRXAOapdc4=; b=FjRBYG1V0v2ua8Ku+/9rSQ5rnkkQa9EaR8QNaueJ9UdvxZHE3vKCevN6KOko7SDr68 R5ISFFFqT5VnIaxUXnN7udOzkgNkkw8zrh8kzI+S7xyuwckYi/sYCheF+oZFqr3jiPU0 5LVqSqj6+65/Fmfq2M2uTOVa1oOmXGnmqndpVwar39eOs/HQ6pcMhBiAMvZREmchKonr mDDd792lKQd+j7UOV4rbwihnqjDXwgFYKRlblpzf4hHGa/8MKmAdVzE3jBJCu5+WAfmG vHGPEGYh4UGOhJDm2yW4ooG1GJnR25VrDFCx/OE8lV8R1d6IlFlYUIoXgNQSnDnpgDJQ HwlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740192272; x=1740797072; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CIR+vaBmCH81gf3lPHKSq4yJjgf5dTcIauRXAOapdc4=; b=IxEYeRfvEgFQxMJ2erYvVDEwbC1eBLOqsjhDdIw4xGGOhExKb5//VwrrzMBvVPRy5H NjhoE3yHdtqR/gs3EUaykI3XJNb0Rc76zsQAif7QjNXxtsmD6ikyqQglQCCTeSprNRig Uo3Jk63Efnd/6IIaKpXhHKWaHuSRNm7wKo5OUf7ahkJtpNYSxasgxSBft6jy2yDFzlyO YjuEjXRwXgY8m7AgFof8O5fosgiH0ZlqMm0Lz4rIAaqRc18ckDOSm4KQjQnFHal0MkA4 gEUGjfEUYzFSIcvga/mkWkuZtVyaQ15mxUDi24PCFgVRtZbXuvpgp6M05Jbhi7Ofpe3c xDGg== X-Forwarded-Encrypted: i=1; AJvYcCUeWkhZFABNRqykTRmH/oivdVD+vLVpkv4N0SN2O9asNxJ6lUCvwmYcFo9b9dER1KJfkd/HfE7AMA==@kvack.org X-Gm-Message-State: AOJu0YwDKSUsu1XuoInE4RSajizu4BQ5QRw2EhawdVuXw/J54lM0PbWr 5m5StO1Otv5ZC5fjmyYgorR2IBVSk5JWv4ahL3kTCrxUA2fIIQr8 X-Gm-Gg: ASbGnctFtWLe55jTtTAYaS4rY7O62drnQgZaOnxGT3ejOlDdpfAz9MEuGSZfgO9wzBb hck8KqEeMmcZ9JInHocQVzeZzEAC01w20XjgyYMFaWd1i6ceKy2FtVLGvo6AxZ4vIgw+nQFU+v8 HaHHGtkYdPPtIG0LNWd6Kw0h4FC9cLytiKFLvmDkm43TPW6GjffPkhC2QsGJN2Scj+oyt1Zsw14 JzjBOaIXAAdpenvRYZBByr5M3luSH0eC4RU0i0PUs3tYKe6Y8XbHch/EzB5KRfPgAls2K44ldva TKV5P75HYCLK6OGrJYiODiB3EHWsr4yN/aHLAPZ81CMjo/hZfzN1hA== X-Google-Smtp-Source: AGHT+IHCy2q5OSVLyb9zJJU+lr9EB5b0ETkZooDfC45u/k9LYYpy905s8TqK2ZkpnWb2o7pn/43yVA== X-Received: by 2002:a05:6a20:d80b:b0:1ee:a420:7c27 with SMTP id adf61e73a8af0-1eef3cd4506mr10581850637.20.1740192271906; Fri, 21 Feb 2025 18:44:31 -0800 (PST) Received: from localhost.localdomain ([2620:10d:c090:400::5:fd1b]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-732547af8acsm14557469b3a.71.2025.02.21.18.44.29 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 21 Feb 2025 18:44:31 -0800 (PST) From: Alexei Starovoitov <alexei.starovoitov@gmail.com> To: bpf@vger.kernel.org Cc: andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, vbabka@suse.cz, bigeasy@linutronix.de, rostedt@goodmis.org, houtao1@huawei.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@suse.com, willy@infradead.org, tglx@linutronix.de, jannh@google.com, tj@kernel.org, linux-mm@kvack.org, kernel-team@fb.com Subject: [PATCH bpf-next v9 0/6] bpf, mm: Introduce try_alloc_pages() Date: Fri, 21 Feb 2025 18:44:21 -0800 Message-Id: <20250222024427.30294-1-alexei.starovoitov@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 1A53720004 X-Stat-Signature: f5yn5smacxukiajqes33ggggnmgccseh X-Rspamd-Server: rspam03 X-HE-Tag: 1740192272-889399 X-HE-Meta: U2FsdGVkX18peR6LqAyj0qE8f0mr3nZLFgPDvcPO3sR+eyXkF7V8NIPRasNr9bh9kSbT4egadPJb3OCbKANr0fMBqFm5Nofcaj0veqaoQOiUrzvkK4dqTutNca3Ng/y4n68C1Axl3AW+c+6Zj9pcN+gEXwY9HSrPxdn6LxhT+6iZXBto/sdgCFSe+5pOH/2muNwtVEeNINlnLdev5GSvpoU1HsEydkDisDe+DjZJu4d/wh99sHzwzXDPMVadql8DdhSqD9/7vPr7VONDCCdWrJyLnslGYWl66pMAYqX8NqkRPswckWM5S1VMInLhhCTlzm20/NIC/DNTnXrKoEiNXN+2evjjvNIhagINMbAXA/ngk/oBdXfWfPa2UQRLTtJvBh5R+thmXwG4pppjf2fGd1+LneEItAyrE60zu5yTeT1+PU7euVHdJbETPRZxUhlLP8bGKmkL91gIf8vhh5wciFbhzm9I5RofT1ALFTVWQULfUv/YPAT49yuGkEXLERBNWoQc6rnKt8u1OnqU41vCs2qXDe5FNhvVICM6FM/Klnj/c29gGWpf4cOGNRyUfcLfbqQQ0rzWzEUZ5mTBnJDk/oIpYQ74hJ5u1xS5LYqArC30hU5qARvFGGx/2qYN4bJJcQt9E8xY23vfcQH2kt212y4dvv4b6UCzhjOygS1AyKV3AOlrSU6Vwoz50oAPMFaFp15h1LYEc9uIqi6mxd6DW/I2MWDAv3QKo3xL8+joVD4eBfMTK/0jKXP8Cd1ziPd3xLk5KVpp6Oa0oJJkwmdjpwdB1TrTEXIioUPOzjcU4jPrn8ELDt/gc/0ze1HeWa1mRKzZt5DmA5DeJH26JVYtkb+cCpbRtO3Hz004g6qBSeS3cukwQ/mzJQSN5jV9cO0DsqIF6JkORl5vN4xrL38eSLV0wcOXevmUBl33sxXYvrAPsKTyvT7taHp1chjFvsLGHFD++5RDdta+VOMywFd NDl57hiX Lj7hAbkZywkxi8wTP9HhNJOQQS938JbS699H6Wsof8fN0G0TP0wqcB1rReI3WZ8P8k4Zzhxc55Jxfb5KIUygT5NinSkWxMtQxME6D7iN/fZ2odgfVN2rK4uXrctetOxOefAaV+DVQjNUd5nQPPxqTIIjSfJgVPeJS+SDXBew0G3GF/y97EMKXmdkm7GgkciRq8QTT6Mnah1SUJtTgaFkSVWxwIymqHQu2X15mTIIcNJt/pR73jrajl9tCT11Rd8VnWNrwqEGQZHXaRf5JXpPMrjqP8DhDTf7WA1hk0cOhOBirPuQsWZ+gPdTM5rqPHgZCnWRRVRNRCr0B99p9iRWBF9Xgeq6/BK58DL5tPavWAI1ekCt+KHtTXfdwaMEZ5EZIu2amygP8yQGeFMLiCUNBEvR7DZfc4+qg/mXpNVA8km6hKDk9cyRj2xRCYlMOPfGTiNxvewNi9ByaYPM= 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
bpf, mm: Introduce try_alloc_pages()
|
expand
|
From: Alexei Starovoitov <ast@kernel.org> Hi All, The main motivation is to make alloc page and slab reentrant and remove bpf_mem_alloc. v8->v9: - Squash Vlastimil's fix/feature for localtry_trylock, and udpate commit log as suggested by Sebastian. - Drop _noprof suffix in try_alloc_pages kdoc - rebase v8: https://lore.kernel.org/bpf/20250213033556.9534-1-alexei.starovoitov@gmail.com/ v7->v8: - rebase: s/free_unref_page/free_frozen_page/ v6->v7: - Took Sebastian's patch for localtry_lock_t as-is with minor addition of local_trylock_acquire() for proper LOCKDEP. Kept his authorship. - Adjusted patch 4 to use it. The rest is unchanged. v6: https://lore.kernel.org/bpf/20250124035655.78899-1-alexei.starovoitov@gmail.com/ v5->v6: - Addressed comments from Sebastian, Vlastimil - New approach for local_lock_t in patch 3. Instead of unconditionally increasing local_lock_t size to 4 bytes introduce local_trylock_t and use _Generic() tricks to manipulate active field. - Address stackdepot reentrance issues. alloc part in patch 1 and free part in patch 2. - Inlined mem_cgroup_cancel_charge() in patch 4 since this helper is being removed. - Added Acks. - Dropped failslab, kfence, kmemleak patch. - Improved bpf_map_alloc_pages() in patch 6 a bit to demo intended usage. It will be refactored further. - Considered using __GFP_COMP in try_alloc_pages to simplify free_pages_nolock a bit, but then decided to make it work for all types of pages, since free_pages_nolock() is used by stackdepot and currently it's using non-compound order 2. I felt it's best to leave it as-is and make free_pages_nolock() support all pages. v5: https://lore.kernel.org/all/20250115021746.34691-1-alexei.starovoitov@gmail.com/ v4->v5: - Fixed patch 1 and 4 commit logs and comments per Michal suggestions. Added Acks. - Added patch 6 to make failslab, kfence, kmemleak complaint with trylock mode. It's a prerequisite for reentrant slab patches. v4: https://lore.kernel.org/bpf/20250114021922.92609-1-alexei.starovoitov@gmail.com/ v3->v4: Addressed feedback from Michal and Shakeel: - GFP_TRYLOCK flag is gone. gfpflags_allow_spinning() is used instead. - Improved comments and commit logs. v3: https://lore.kernel.org/bpf/20241218030720.1602449-1-alexei.starovoitov@gmail.com/ v2->v3: To address the issues spotted by Sebastian, Vlastimil, Steven: - Made GFP_TRYLOCK internal to mm/internal.h try_alloc_pages() and free_pages_nolock() are the only interfaces. - Since spin_trylock() is not safe in RT from hard IRQ and NMI disable such usage in lock_trylock and in try_alloc_pages(). In such case free_pages_nolock() falls back to llist right away. - Process trylock_free_pages llist when preemptible. - Check for things like unaccepted memory and order <= 3 early. - Don't call into __alloc_pages_slowpath() at all. - Inspired by Vlastimil's struct local_tryirq_lock adopted it in local_lock_t. Extra 4 bytes in !RT in local_lock_t shouldn't affect any of the current local_lock_t users. This is patch 3. - Tested with bpf selftests in RT and !RT and realized how much more work is necessary on bpf side to play nice with RT. The urgency of this work got higher. The alternative is to convert bpf bits left and right to bpf_mem_alloc. v2: https://lore.kernel.org/bpf/20241210023936.46871-1-alexei.starovoitov@gmail.com/ v1->v2: - fixed buggy try_alloc_pages_noprof() in PREEMPT_RT. Thanks Peter. - optimize all paths by doing spin_trylock_irqsave() first and only then check for gfp_flags & __GFP_TRYLOCK. Then spin_lock_irqsave() if it's a regular mode. So new gfp flag will not add performance overhead. - patches 2-5 are new. They introduce lockless and/or trylock free_pages_nolock() and memcg support. So it's in usable shape for bpf in patch 6. v1: https://lore.kernel.org/bpf/20241116014854.55141-1-alexei.starovoitov@gmail.com/ Alexei Starovoitov (5): mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation mm, bpf: Introduce free_pages_nolock() memcg: Use trylock to access memcg stock_lock. mm, bpf: Use memcg in try_alloc_pages(). bpf: Use try_alloc_pages() to allocate pages for bpf needs. Sebastian Andrzej Siewior (1): locking/local_lock: Introduce localtry_lock_t include/linux/bpf.h | 2 +- include/linux/gfp.h | 23 ++++ include/linux/local_lock.h | 70 ++++++++++ include/linux/local_lock_internal.h | 146 ++++++++++++++++++++ include/linux/mm_types.h | 4 + include/linux/mmzone.h | 3 + kernel/bpf/arena.c | 5 +- kernel/bpf/syscall.c | 23 +++- lib/stackdepot.c | 10 +- mm/internal.h | 1 + mm/memcontrol.c | 52 +++++--- mm/page_alloc.c | 200 ++++++++++++++++++++++++++-- mm/page_owner.c | 8 +- 13 files changed, 506 insertions(+), 41 deletions(-)