Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

To: Steven Rostedt <rostedt@xxxxxxxxxxx>
Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
Date: Fri, 13 Dec 2024 10:57:52 -0800
Cc: Sebastian Sewior <bigeasy@xxxxxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxx>, bpf <bpf@xxxxxxxxxxxxxxx>, Andrii Nakryiko <andrii@xxxxxxxxxx>, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Hou Tao <houtao1@xxxxxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, shakeel.butt@xxxxxxxxx, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>, Kernel Team <kernel-team@xxxxxx>
In-reply-to: <CAADnVQ+R3ABHX2sdiTqjgZDgn0==cA3gryx9h_uDktU6P2s2aw@mail.gmail.com>
References: <20241210023936.46871-1-alexei.starovoitov@gmail.com> <20241210023936.46871-2-alexei.starovoitov@gmail.com> <Z1fSMhHdSTpurYCW@casper.infradead.org> <Z1gEUmHkF1ikgbor@tiehlicka> <CAADnVQKj40zerCcfcLwXOTcL+13rYzrraxWABRSRQcPswz6Brw@mail.gmail.com> <20241212150744.dVyycFUJ@linutronix.de> <Z1r_eKGkJYMz-uwH@tiehlicka> <20241212153506.dT1MvukO@linutronix.de> <20241212104809.1c6cb0a1@batman.local.home> <20241212160009.O3lGzN95@linutronix.de> <20241213124411.105d0f33@gandalf.local.home> <CAADnVQ+R3ABHX2sdiTqjgZDgn0==cA3gryx9h_uDktU6P2s2aw@mail.gmail.com>

On Fri, Dec 13, 2024 at 10:44 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> If hard-irq acquired rt_mutex B (spin_lock or spin_trylock doesn't
> change the above analysis),

attempting to spin_lock from irq is obviously not safe. scratch that part.

References:
- [PATCH bpf-next v2 0/6] bpf, mm: Introduce __GFP_TRYLOCK
  - From: Alexei Starovoitov
- [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Matthew Wilcox
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Michal Hocko
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Michal Hocko
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Steven Rostedt
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Sebastian Sewior
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Steven Rostedt
- Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
  - From: Alexei Starovoitov

Prev by Date: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Next by Date: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Previous by thread: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Next by thread: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation
Index(es):
- Date
- Thread

[Index of Archives] [Linux ARM Kernel] [Linux ARM] [Linux Omap] [Fedora ARM] [IETF Annouce] [Bugtraq] [Linux OMAP] [Linux MIPS] [eCos] [Asterisk Internet PBX] [Linux API]