[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96325519f8f05d7289ec9b0af4e89da28c432e4f.camel@scylladb.com>
Date: Wed, 13 Mar 2024 23:58:44 +0200
From: Avi Kivity <avi@...lladb.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Oskolkov
<posk@...gle.com>
Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, Boqun Feng
<boqun.feng@...il.com>, Andrew Hunter <ahh@...gle.com>, Maged Michael
<maged.michael@...il.com>, gromer@...gle.com, Benjamin Herrenschmidt
<benh@...nel.crashing.org>, Paul Mackerras <paulus@...ba.org>, Michael
Ellerman <mpe@...erman.id.au>
Subject: Re: [RFC PATCH 0/2] Introduce serialized smp_call_function APIs
[resend in plain text for the list]
On Wed, 2024-03-13 at 16:56 -0400, Mathieu Desnoyers wrote:
> commit 944d5fe50f3f ("sched/membarrier: reduce the ability to hammer
> on sys_membarrier")
> introduces a mutex over all membarrier operations to reduce its
> ability
> to slow down the rest of the system.
>
> This RFC series has two objectives:
>
> 1) Move this mutex to the smp_call_function APIs so other system
> calls
> using smp_call_function IPIs are limited in the same way,
>
> 2) Restore scalability of MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ with
> MEMBARRIER_CMD_FLAG_CPU, which targets specific CPUs with IPIs.
> This may or may not be useful, and I would welcome benchmarks from
> users of this feature to figure out if this is worth it.
>
I see this doesn't restore scaling of MEMBARRIER_CMD_PRIVATE_EXPEDITED,
which I use (and wasn't aware was broken).
I don't have comments on the patches, but do have ideas on how to work
around the problem in Seastar. So this was a useful heads-up for me.
Powered by blists - more mailing lists