[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1ZzTvJAm8SCbZY/@hirez.programming.kicks-ass.net>
Date: Mon, 24 Oct 2022 13:13:18 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: x86@...nel.org, willy@...radead.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
aarcange@...hat.com, kirill.shutemov@...ux.intel.com,
jroedel@...e.de, ubizjak@...il.com
Subject: Re: [PATCH 10/13] x86/mm/pae: Be consistent with pXXp_get_and_clear()
On Sat, Oct 22, 2022 at 10:53:42AM -0700, Linus Torvalds wrote:
> On Sat, Oct 22, 2022 at 4:48 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > +
> > +#define pxx_xchg64(_pxx, _ptr, _val) ({ \
> > + _pxx##val_t *_p = (_pxx##val_t *)_ptr; \
> > + _pxx##val_t _o = *_p; \
> > + do { } while (!try_cmpxchg64(_p, &_o, (_val))); \
> > + native_make_##_pxx(_o); \
> > +})
>
> I think this could just be a "xchp64()", but if the pte/pmd code is
> the only thing that actually wants this on 32-bit architectures, I'm
> certainly ok with making it be specific to just this code, and calling
> it "pxx_xchg()".
Regular xchg64() didn't work, the casting crud there is required because
of how pxx_t is a struct.
Now I could obviously do a xchg64(), but then we'd still need this
wrapper -- and yeah, I don't know how many other users there are.
Powered by blists - more mailing lists