On Wed, Aug 12, 2020 at 12:44 PM Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > [...] > > > 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? > > Not really. This would not take care of the fact that we would end up multiplying > the number of commands as we allow combinations. E.g. if we ever want to have RSEQ > work in private and global, and in non-expedited and expedited, we end up needing: > > - CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ > - CMD_PRIVATE_EXPEDITED_RSEQ > - CMD_PRIVATE_RSEQ > - CMD_REGISTER_GLOBAL_EXPEDITED_RSEQ > - CMD_GLOBAL_EXPEDITED_RSEQ > - CMD_GLOBAL_RSEQ > > The only thing we would save by OR'ing it with the SYNC_CORE command is the additional > list: > > - CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_SYNC_CORE > - CMD_PRIVATE_EXPEDITED_RSEQ_SYNC_CORE > - CMD_PRIVATE_RSEQ_SYNC_CORE > - CMD_REGISTER_GLOBAL_EXPEDITED_RSEQ_SYNC_CORE > - CMD_GLOBAL_EXPEDITED_RSEQ_SYNC_CORE > - CMD_GLOBAL_RSEQ_SYNC_CORE > > But unless we receive feedback that doing a membarrier with RSEQ+sync_core all in > one go is a significant use-case, I am tempted to leave out that scenario for now. > If we go for new commands, this means we could add (for private-expedited-rseq): > > - MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ, > - MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ, > > I do however have use-cases for using RSEQ across shared memory (between > processes). Not currently for a rseq-fence, but for rseq acting as per-cpu > atomic operations. If I ever end up needing rseq-fence across shared memory, > that would result in the following new commands: > > - MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED_RSEQ, > - MEMBARRIER_CMD_GLOBAL_EXPEDITED_RSEQ, > > The remaining open question is whether it would be OK to define a new > membarrier flag=MEMBARRIER_FLAG_CPU, which would expect an additional > @cpu parameter. Hi Mathieu, I do not think there is any reason to wait for additional feedback, so I believe we should finalize the API/ABI. I see two issues to resolve: 1: how to combine commands: - you do not like adding new commands that are combinations of existing ones; - you do not like ORing. => I'm not sure what other options we have here? 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. Please let me know your thoughts. Thanks, Peter
