linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Sebastian Sewior <bigeasy@linutronix.de>,
	bpf <bpf@vger.kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	 Martin KaFai Lau <martin.lau@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Michal Hocko <mhocko@suse.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	linux-mm <linux-mm@kvack.org>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Introduce try_alloc_pages for 6.15
Date: Mon, 31 Mar 2025 17:57:50 -0700	[thread overview]
Message-ID: <CAADnVQLpSkaB7WtZDPiJ6qRBUjLE4tkwGo0i6Rqoko1aeLML4Q@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wj1jFH2Gc2Pq+-m_32BL9-CbdD7vReTJgd7Wbt2_EnH3Q@mail.gmail.com>

On Mon, Mar 31, 2025 at 8:35 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 31 Mar 2025 at 02:59, Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > Yes I was going to point out that e.g. "nmisafe_local_lock_irqsave()" seems
> > rather misleading to me as this operation is not a nmisafe one?
>
> Yeah, it's not a great name either, IO admit.
>
> > The following attempt [2] meant there would be only a new local_trylock_t
> > type, but the existing locking operations would remain the same, relying on
> > _Generic() parts inside them.
>
> Hmm. I actually like that approach.
>
> That avoids having the misleading operation naming. IOW, you'd not
> have a "localtry" when it's not a trylock, and you'd not have
> "nmisafe" when it's not an operation that is actually nmi-safe.
>
> The downside of _Generic() is that it's a bit subtle and can hide the
> actual operation, but I think that in this situation that's the whole
> point.
>
> So yes, I'd vote for the "let's just introduce the new type that has
> the required 'acquired' field, and then use a _Generic() model to
> automatically pick the right op".

Here is the patch that goes back to that approach:

https://lore.kernel.org/bpf/20250401005134.14433-1-alexei.starovoitov@gmail.com/

btw the compiler error when local_lock_t (instead of
local_trylock_t) is passed into local_trylock_irqsave()
is imo quite readable:

../mm/memcontrol.c: In function ‘consume_stock’:
../include/linux/local_lock_internal.h:136:20: error: assignment to
‘local_trylock_t *’ from incompatible pointer type ‘local_lock_t *’
[-Werror=incompatible-pointer-types]
  136 |                 tl = this_cpu_ptr(lock);                        \
      |                    ^
../include/linux/local_lock.h:76:9: note: in expansion of macro
‘__local_trylock_irqsave’
   76 |         __local_trylock_irqsave(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~~~~
../mm/memcontrol.c:1790:19: note: in expansion of macro ‘local_trylock_irqsave’
 1790 |         else if (!local_trylock_irqsave(&memcg_stock.stock_lock, flags))
      |                   ^~~~~~~~~~~~~~~~~~~~~


  reply	other threads:[~2025-04-01  0:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-27 14:51 Alexei Starovoitov
2025-03-30 20:42 ` Linus Torvalds
2025-03-30 20:56   ` Linus Torvalds
2025-03-30 21:49     ` Alexei Starovoitov
2025-03-31  7:14       ` Sebastian Sewior
2025-03-31  9:59         ` Vlastimil Babka
2025-03-31 15:35           ` Linus Torvalds
2025-04-01  0:57             ` Alexei Starovoitov [this message]
2025-03-30 21:30   ` Alexei Starovoitov
2025-03-30 22:08     ` Linus Torvalds
2025-03-31  0:33       ` Alexei Starovoitov
2025-03-31 13:11       ` Vlastimil Babka
2025-03-31 14:59     ` Johannes Weiner
2025-03-30 21:05 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADnVQLpSkaB7WtZDPiJ6qRBUjLE4tkwGo0i6Rqoko1aeLML4Q@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.lau@kernel.org \
    --cc=mhocko@suse.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=shakeel.butt@linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox