Re: [Xen-devel] [PATCH v3 2/2] rwlock: allow recursive read locking when already locked in write mode

[Julien Grall <julien@xxxxxxx>]

On 24/02/2020 10:10, Roger Pau Monné wrote:
> On Mon, Feb 24, 2020 at 10:05:39AM +0000, Julien Grall wrote:
> > Hi Roger,
> >
> > On 24/02/2020 08:44, Roger Pau Monne wrote:
> > > Allow a CPU already holding the lock in write mode to also lock it in
> > > read mode. There's no harm in allowing read locking a rwlock that's
> > > already owned by the caller (ie: CPU) in write mode. Allowing such
> > > accesses is required at least for the CPU maps use-case.
> > >
> > > In order to do this reserve 12bits of the lock, this allows to support
> > > up to 4096 CPUs. Also reduce the write lock mask to 2 bits: one to
> > > signal there are pending writers waiting on the lock and the other to
> > > signal the lock is owned in write mode.
> > >
> > > This reduces the maximum number of concurrent readers from 16777216 to
> > > 262144, I think this should still be enough, or else the lock field
> > > can be expanded from 32 to 64bits if all architectures support atomic
> > > operations on 64bit integers.
> > >
> > > Fixes: 5872c83b42c608 ('smp: convert the cpu maps lock into a rw lock')
> > > Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
> > > Reported-by: Jürgen Groß <jgross@xxxxxxxx>
> > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > ---
> > > Changes since v2:
> > >    - Use atomic_and to clear the writers part of the lock when
> > >      write-unlocking.
> > >    - Reduce writer-related area to 14bits.
> > >    - Include xen/smp.h for Arm64.
> > OOI, is it to use smp_processor_id()?
> Yes, or else I would get errors when building asm-offsets on Arm64
> IIRC.
Thank you for the confirmation.

Reviewed-by: Julien Grall <julien@xxxxxxx>

Cheers,

> Thanks, Roger.
--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel