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 <jbeul...@suse.com> Reported-by: Jürgen Groß <jgr...@suse.com> Signed-off-by: Roger Pau Monné <roger....@citrix.com> --- 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()? Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
