Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200811000959.2486636-1-posk@google.com> <20200811062733.GP3982@worktop.programming.kicks-ass.net>
 <CAFTs51XK0HLwCCvXCcfE5P7a4ExANPNPw7UvNigwHZ8sZVP+nQ@mail.gmail.com> <1003774683.6088.1597257002027.JavaMail.zimbra@efficios.com>
In-Reply-To: <1003774683.6088.1597257002027.JavaMail.zimbra@efficios.com>
From:   Peter Oskolkov <posk@posk.io>
Date:   Wed, 12 Aug 2020 11:48:49 -0700
Message-ID: <CAFTs51XJhKXn7M2U2dZpFRsTrog4juy=UQfbtcdJfOj5TUSbqQ@mail.gmail.com>
Subject: Re: [PATCH 1/2 v3] rseq/membarrier: add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Peter Oskolkov <posk@google.com>, paulmck <paulmck@kernel.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Paul Turner <pjt@google.com>,
        Chris Kennelly <ckennelly@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 12, 2020 at 11:30 AM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:

[...]

> "flags" is there to allow extensibility without requiring to add new
> membarrier commands for every change. Even though it is not used now,
> I don't think re-purposing it is a good idea. What is wrong with just
> adding an additional "cpu" parameter to the system call ?

Can we do that? I thought adding an additional parameter means adding
another syscall (ABI => parameter types/count cannot change?)

> A "flags" parameter is very common for system calls. I don't see why
> we should change its name, especially given it is already exposed and
> documented as "flags" in man pages.
>

[...]

> We basically have the following feature matrix:
>
> - private / global
> - expedited / non-expedited
> - sync-core / non-sync-core
> - rseq-fence / non-rseq-fence
>
> For a total of about 16 combinations in total if we want to support them
> all.
>
> We can continue to add separate commands for new combinations, but if we
> want to allow them to be combined, using flags rather than adding extra
> commands would have the advantage of keeping the number of commands
> manageable.
>
> However, if there is no actual use-case for combining a membarrier sync-core
> and a membarrier rseq-fence, then it limits the number of commands and maybe
> then it's acceptable to add the rseq-fence as a separate membarrier command.
>
> I prefer to have this discussion now rather than once we get to the point of
> having 40 membarrier commands for all possible combinations.

All commands are currently distinct bits, but are treated as separate commands.
One way of doing what you suggest is to allow some commands to be bitwise-ORed.

So, for example, the user could call

membarrier(CMD_PRIVATE_EXPEDITED_SYNC_CORE | CMD_PRIVATE_EXPEDITED_RSEQ, cpu_id)

Is this what you have in mind?

[...]

Thanks,
Peter