[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZZ7qiIDFDEMEfNiS@andrea>
Date: Wed, 10 Jan 2024 20:05:44 +0100
From: Andrea Parri <parri.andrea@...il.com>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
mathieu.desnoyers@...icios.com, paulmck@...nel.org, corbet@....net,
mmaas@...gle.com, hboehm@...gle.com, striker@...ibm.com,
charlie@...osinc.com, rehn@...osinc.com,
linux-riscv@...ts.infradead.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] membarrier: Create
Documentation/scheduler/membarrier.rst
Hi Randy,
> > +MEMBARRIER_CMD_{PRIVATE,GLOBAL}_EXPEDITED - Architecture requirements
> > +=====================================================================
> > +
> > +Memory barriers before updating rq->curr
> > +----------------------------------------
> > +
> > +The command requires each architecture to have a full memory barrier after
> > +coming from user-space, before updating rq->curr. This barrier is implied
> > +by the sequence rq_lock(); smp_mb__after_spinlock() in __schedule(). The
> > +barrier matches a full barrier in the proximity of the membarrier system
> > +call exit, cf. membarrier_{private,global}_expedited().
> > +
>
> What does "The command" refer to above and below, please?
The term was meant to refer to any of MEMBARRIER_CMD_PRIVATE_EXPEDITED and
MEMBARRIER_CMD_GLOBAL_EXPEDITED (from the section title); FWIW, this seems
to align with the terminology adopted in MEMBARRIER(2) for example.
Mmh, unless I get a better idea, I'll expand those occurrences to:
"The commands MEMBARRIER_CMD_PRIVATE_EXPEDITED and MEMBARRIER_CMD_GLOBAL_EXPEDIDED
require [...]"
Andrea
Powered by blists - more mailing lists