Hi, On Mon, Sep 19, 2022 at 12:25 PM Alexander Aring <[email protected]> wrote: > > Hi, > > On Fri, Sep 16, 2022 at 2:43 PM Alexander Aring <[email protected]> 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 <[email protected]> > > --- > > 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
s/mutex/spinlock/ - Alex
