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 08B4FC02180 for ; Thu, 16 Jan 2025 02:45:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 598C9280002; Wed, 15 Jan 2025 21:45:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54923280001; Wed, 15 Jan 2025 21:45:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4112F280002; Wed, 15 Jan 2025 21:45:13 -0500 (EST) 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 22481280001 for ; Wed, 15 Jan 2025 21:45:13 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BEF9243D68 for ; Thu, 16 Jan 2025 02:45:12 +0000 (UTC) X-FDA: 83011773264.07.FA30151 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf03.hostedemail.com (Postfix) with ESMTP id D68FF2000D for ; Thu, 16 Jan 2025 02:45:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iPI04c5H; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 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=1736995510; 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=FUUyrqUxzYlS5Wo3hrGvUlpzZSewOKz5LWx+ks3q5Y8=; b=h62+2iwVw9WhKAeiu/ajbFerXT5Q5nRVkcjcjsq+9R6+FovrlrZxOrNEdv+9AQNwdrKf+t Qh9PBmJltMdd7pnACpldYPxpSvnqewCsYlVr9DyE0MbEasO6c4vWWTqoGONZqO3s8yqfs4 loufKcs9CVIwE2PHkkkIX0ov0eh+ByY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iPI04c5H; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 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=1736995510; a=rsa-sha256; cv=none; b=ZACy2ln+qOFT2JrZqv4huRSiMvx9ln2Tnq9FPbqKKcftgR8H+D8yFS4B5I3SB3wQ1s1VJ7 cuDJN/PHi7LmR5JPOqfKrrjX37SinikBqp3SBREgU0LtfaBM9xBrlL82bzzL1P00VYBR1g tU8wBVvwuTeFJK0d7iKwF76GekpN/O8= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3863494591bso220083f8f.1 for ; Wed, 15 Jan 2025 18:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736995509; x=1737600309; 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=FUUyrqUxzYlS5Wo3hrGvUlpzZSewOKz5LWx+ks3q5Y8=; b=iPI04c5H6WIUGBVPtV8NP7mJNzprCXL8TqK1cUUpWTfRo3OkhqMVu63cbMwYWV9Gex /Q/LSs9isJccY9Sh4tHBt0CwzDHtOnWhJ2Fhpbaj8Gen/poub/wM0qnUXzJaeRBzUvB9 nhakIl/i8w5139Y7TbKiJ/ul+eSkM0p4fS5e7Jm4ZhFa0hG95odujitNrrdeDKKvz2Xm CZbaRNkFCRuPQdMNTTiOHCD4wZt6oZUCW8+KeoD9UKzM7Zh5gLdlAH45QXs756+thFcI wIAYYx+S1tlK1h19/7gS2lizQnwo3ad+MOQ1jv2Wt+1XS+g0G1Es04K87dqeYtVJfwt7 HWrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736995509; x=1737600309; 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=FUUyrqUxzYlS5Wo3hrGvUlpzZSewOKz5LWx+ks3q5Y8=; b=wEr+kqEMlXC5MhMTvQ6JXoTwPV0jTN+1ousM5tpfrpBDbYAMKS17eSXKzAKiepVUgq nTSUF55Ciq2NKUoDdkg2+8PbiITCF1rcqyUpToUMSM44iSCRPd/ZB5yvAw1L4rEZLX6J vAAaJDgSZtaLEYEtAYNlB6HBLZu5akEDekNXW21hnPYEQDa11ckS7Tk5zJdSiJipLW0G SufMTEke2cg3uPIoo7wPXM3ffv6LhGqccjE1v0TvjNrwamGNes6LGv8SP8eqVny4q1gd iL5QBjKhwMna2qZky2W9H9fzJ9BOjKPCawOvGbcqoQoCdLIywLR8dazUk88Y66+NwAcI +eEQ== X-Forwarded-Encrypted: i=1; AJvYcCUPQKpJnaCpyEnkN12CZFPW57w3BFCbN4q8N8eGU45rWW0k/w7eQ7fjGNw5Rl5le0UEaEqTt9WG3w==@kvack.org X-Gm-Message-State: AOJu0Ywb1FNWSUVLokpAscAq76uYxkZh8m222e8Twv0DNvvPNDGPO2CW Y1laJvj6RCG0fsWLHUEVqijl82oS5cr84KptzQ2S0ObKQg553CkMYo30oJHudlHroOssItdUIIC n4U3N+d4ZQct7BPYpCK/FZ8FPEpM= X-Gm-Gg: ASbGncvtAxxCWEs4y8sOKU6hk4ZLw2W6uGaZOMZ3YR7P9MPgQTC8u9e0gZ0bM88pi4p aWJwMm04mbt02k5WEC3OvZVzPPmx6XO1z28s7fWMZs5YyHt2gOLgeEA== X-Google-Smtp-Source: AGHT+IHnw+CRA39JAHy5NAOmwN2RTgLmf6uco3ZjOjO86oSkjt79ZCqv0L7sFDm55OIKY4IKnUDiZhFViEnIREMORHQ= X-Received: by 2002:a5d:6da1:0:b0:385:eecb:6f02 with SMTP id ffacd0b85a97d-38a872ebe97mr27508287f8f.28.1736995509261; Wed, 15 Jan 2025 18:45:09 -0800 (PST) MIME-Version: 1.0 References: <20250115021746.34691-1-alexei.starovoitov@gmail.com> <20250115021746.34691-2-alexei.starovoitov@gmail.com> <9fb94763-69b2-45bd-bc54-aef82037a68c@suse.cz> In-Reply-To: From: Alexei Starovoitov Date: Wed, 15 Jan 2025 18:44:56 -0800 X-Gm-Features: AbW1kvZYd19foovg0gB4qxvYaJMO27oXbcme34UNsIKlUE206yTCEH09JZOnY-g Message-ID: Subject: Re: [PATCH bpf-next v5 1/7] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation To: Shakeel Butt Cc: Vlastimil Babka , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , 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: rspam09 X-Rspamd-Queue-Id: D68FF2000D X-Stat-Signature: utyaeimeabjj3ja3we1hgy73qy1h4dis X-HE-Tag: 1736995510-525050 X-HE-Meta: U2FsdGVkX18Mn6XSkJGurp+D0hg1qXUw6oXZ1+nZkv5140Cra4/G8WrnwpzO/RlUxrYz+F7YWqUuQXJA3gLaVyrXLNKSRiPnIMYNrkSfCQ84FO8nsD9ArYQ+F7lYM/y0fB8J7k1XReFac+dpcDV0DmiOV+K9J5JdiM2THLOBzd380cpz9hsUf7wy1YmKa2nAR66Bhp0f+um7Ge3tWW4pV5HmRr+TBK2pwcLaItSKbnyR6tOKLblLZup7Fo8kIb7zaBB4fVkXJoAfWf11gmUzZK5XLR48E2CrOsAQrcO/5oaOvXSuE998rHNnoQLW4quYOBcsbqUGDkzE1ZKfqCPK2gHbses98aK0AKodiEDQP1qnTyyQ68+1lLYiySZM7l2IhYebuvxbM23mzGP0H5bB2PWNdtA0YIWRiTyE5hna3Jz7S5GaS/SpdbEHCNfegxqhG6i2LCmdWnBI5vhCDB8uxLPPvz4N7DbcGNPNzEv9m4G04YmHKpWxnaUZ5apgDUWz2DgdEAvYNM+1dAl3bopgdjDIii8k4IkKE2my7ivGwaafnp1T2qc7dYDti4Gm22EPUJXXu2rFFjQzQEoHhwcsVT5n8J/Fd9sA9jcdQpd3wNklwy24iBnB/eIHeSpav/G6JfOKjhvMj4jt01jdodMchE8XAc9z1HSS5b8TyUvONoirIKeAZ7PdUf+7+my4SyxVaGMiFrmvvrlUVdGmb0HWPm1f5EwRXinHH/NydQQEB91b7XpIIrRWVF5KORoUBUsxm6uHe6GLFK2JcXDBBwj5Rh0tXk/obgyYG/NkVmRL6UUkfOjBqNYfjVbIjCYLMzFwJtzvG8L0DM873aW13AHo93elAoh+WJ/LYeyEimrdgY1BcsGILfP0JVM+HwnB6/fJhFao9MNBHh9+9cZMFkP7MWyAOtABCQCp/uwh03QnRH2ecfHsiC2MLAIrx4cF6zaO2hwC+Sj1UbHHmOfNtlM sciBu5vo 8bGQcu4ylYq5CjwxnafnchJ6+1L/y6dcgrittuuJGgsIKZzguGXC5Cm6gwPIPu6rvbSIMoNSYh7pg78ALuG/MNcQGoaQYgx7t3Nd/+9Pshwn0UZBdkgXn6oK0dM5UcgkbsU6PNCrjtR+srRDPpG0GvpLHM/zfCQZhYEiUC0ZFOFxz6zvz2/YpHpkkQ7H3/JFzUO2S6Qg0f+VuKAszUqndsk5Hus3NN0Gk0ZlhzkafRKPdNhzNooBmRLQdmciCsQ158X7BRO0shkwkghUG4aseBrMKevSbayxWFKYGSz7wtCBz+mZcJeAKDAZyTfgS61wqVcVgZBcPUj8cF3cI3EVS0GDoqQkaoCpdEYd0uUS8y3t7J1HdkicvEqkwgEft/O3oDjW3Evp4XLw8lB0= 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, Jan 15, 2025 at 3:47=E2=80=AFPM Shakeel Butt wrote: > > On Wed, Jan 15, 2025 at 03:00:08PM -0800, Alexei Starovoitov wrote: > > On Wed, Jan 15, 2025 at 3:19=E2=80=AFAM Vlastimil Babka wrote: > > > > > > > > Sorry missed your response here. > > > > What about set_page_owner() from post_alloc_hook() and it's stackdepo= t > > > saving. I guess not an issue until try_alloc_pages() gets used later,= so > > > just a mental note that it has to be resolved before. Or is it actual= ly safe? > > > > set_page_owner() should be fine. > > save_stack() has in_page_owner recursion protection mechanism. > > > > stack_depot_save_flags() may be problematic if there is another > > path to it. > > I guess I can do: > > > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > > index 245d5b416699..61772bc4b811 100644 > > --- a/lib/stackdepot.c > > +++ b/lib/stackdepot.c > > @@ -630,7 +630,7 @@ depot_stack_handle_t > > stack_depot_save_flags(unsigned long *entries, > > prealloc =3D page_address(page); > > } > > There is alloc_pages(gfp_nested_mask(alloc_flags)...) just couple of > lines above. How about setting can_alloc false along with the below > change for this case? argh. Just noticed this code path: free_pages_prepare __reset_page_owner save_stack(GFP_NOWAIT | __GFP_NOWARN); stack_depot_save(entries, nr_entries, flags); stack_depot_save_flags(entries, nr_entries, alloc_flags, STACK_DEPOT_FLAG_CAN_ALLOC); bool can_alloc =3D depot_flags & STACK_DEPOT_FLAG_CAN_ALLOC; if (unlikely(can_alloc && !READ_ONCE(new_pool))) { page =3D alloc_pages(gfp_nested_mask(alloc_flags), DEPOT_POOL_ORDER); > Or we can set ALLOC_TRYLOCK in core alloc_pages() > for !gfpflags_allow_spinning(). so gfpflags_allow_spinning() approach doesn't work out of the door, since free_pages don't have gfp flags. Passing FPI flags everywhere is too much churn. I guess using the same gfp flags as try_alloc_pages() in __reset_page_owner() should work. That will make gfpflags_allow_spinning()=3D=3Dtrue in stack_depot. In an earlier email I convinced myself that current->in_page_owner recursion protection in save_stack() is enough, but looks like it's not. We could be hitting tracepoint somewhere inside alloc_pages() then alloc_pages -> tracepoint -> bpf -> free_pages_nolock -> __free_unref_page -> free_pages_prepare -> save_stack(GFP_NOWAIT | __GFP_NOWARN); and this save_stack will be called for the first time. It's not recursing into itself. Then: -> stack_depot_save_flags -> alloc_pages(GFP_NOWAIT) -> boom. So looks like __reset_page_owner() has to use !gfpflags_allow_spinning() flags and stack_depot_save_flags() has to do: if (!gfpflags_allow_spinning(alloc_flags)) can_alloc =3D false; raw_spin_trylock_irqsave(&pool_lock, ..) Will code this up. Unless there are better ideas.