Hi, On Fri, Sep 16, 2022 at 2:43 PM Alexander Aring <aahri...@redhat.com> wrote: > > This patch changes the ls_cb_mutex to a rw lock. The hotpath in > dlm_add_cb() can be called by different lkbs at the same time. Currently > parallel dlm_add_cb() could block because the cb mutex. To change that > we using a rw lock and use a readers lock in dlm_add_cb() only. The cb > mutex is only needed that dlm_callback_suspend() and > dlm_callback_resume() cannot run at the same time as the specific part > in dlm_add_cb() those will use a writers lock to stop any callback > queueing in dlm_add_cb(). > > Signed-off-by: Alexander Aring <aahri...@redhat.com> > --- > fs/dlm/ast.c | 12 ++++++------ > fs/dlm/dlm_internal.h | 2 +- > fs/dlm/lockspace.c | 2 +- > 3 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/fs/dlm/ast.c b/fs/dlm/ast.c > index 6e07c151ad28..43588c8ab5fc 100644 > --- a/fs/dlm/ast.c > +++ b/fs/dlm/ast.c > @@ -200,13 +200,13 @@ void dlm_add_cb(struct dlm_lkb *lkb, uint32_t flags, > int mode, int status, > if (!prev_seq) { > kref_get(&lkb->lkb_ref); > > - mutex_lock(&ls->ls_cb_mutex); > + read_lock(&ls->ls_cb_lock); > if (test_bit(LSFL_CB_DELAY, &ls->ls_flags)) { > list_add(&lkb->lkb_cb_list, &ls->ls_cb_delay);
I drop this patch because the list_add() must be protected against possible parallel list_add() to the per lockspace ls_cb_delay list. However this optimization makes sense because the LSFL_CB_DELAY is a very rare case. I let it be a mutex and look later again into this for a possible optimization regarding the LSFL_CB_DELAY case here. - Alex