[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFTs51WfWCGPDXy7YVNmfE8zjk98L8+V4erWUTofeYOJBJN-WQ@mail.gmail.com>
Date: Tue, 25 Aug 2020 10:22:38 -0700
From: Peter Oskolkov <posk@...k.io>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-arch <linux-arch@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Peter Oskolkov <posk@...gle.com>, paulmck <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Paul Turner <pjt@...gle.com>,
Chris Kennelly <ckennelly@...gle.com>
Subject: Re: [PATCH 1/2 v3] rseq/membarrier: add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
On Tue, Aug 25, 2020 at 9:58 AM Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
>
[...]
>
> Concretely speaking, let's just add a new membarrier command for the use-case
> at hand. All other ways of doing things we have discussed are tricky to expose
> in a way that is discoverable by user-space through the QUERY command. (using
> a flag, or OR'ing many commands together)
>
> >
> > 2: should @flags be repurposed for cpu_id, or MEMBARRIER_FLAG_CPU
> > added with a new syscall parameter.
> > => I'm still not sure a new parameter can be cleanly added, but I can try
> > it in the next patchset if you prefer it this way.
>
> Yes please, it's easy to implement and we'll quickly see if anyone yells. If
> it turns out to be a bad idea, you can always blame me. ;-)
>
> In summary:
>
> - We add 2 new membarrier commands:
> - MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ
> - MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
>
> - We reserve a membarrier flag:
>
> enum membarrier_flag {
> MEMBARRIER_FLAG_CPU = (1 << 0),
> }
>
> So for CMD_PRIVATE_EXPEDITED_RSEQ, if flags & MEMBARRIER_FLAG_CPU is true,
> then we expect the additional "int cpu" parameter (3rd parameter). Else the cpu
> parameter is unused.
>
> Are you OK with this approach ?
Yes, thanks for looking into this. I'll send a v4 later this week.
Thanks,
Peter
[...]
Powered by blists - more mailing lists