Re: [Xen-devel] [PATCH 2/2] smp: convert cpu_hotplug_begin into a blocking lock acquisition

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Feb 19, 2020 at 02:44:12PM +0100, Jan Beulich wrote:
> On 19.02.2020 14:22, Roger Pau Monné wrote:
> > On Wed, Feb 19, 2020 at 01:59:51PM +0100, Jan Beulich wrote:
> >> On 13.02.2020 12:32, Roger Pau Monne wrote:
> >>> Don't allow cpu_hotplug_begin to fail by converting the trylock into a
> >>> blocking lock acquisition. Write users of the cpu_add_remove_lock are
> >>> limited to CPU plug/unplug operations, and cannot deadlock between
> >>> themselves or other users taking the lock in read mode as
> >>> cpu_add_remove_lock is always locked with interrupts enabled. There
> >>> are also no other locks taken during the plug/unplug operations.
> >>
> >> I don't think the goal was deadlock avoidance, but rather limiting
> >> of the time spent spinning while trying to acquire the lock, in
> >> favor of having the caller retry.
> > 
> > Now that the contention between read-only users is reduced as those
> > can take the lock in parallel I think it's safe to switch writers to
> > blocking mode.
> 
> I'd agree if writers couldn't be starved by (many) readers.

AFAICT from the rw lock implementation readers won't be able to pick
the lock as soon as there's a writer waiting, which should avoid this
starvation?

You still need to wait for current readers to drop the lock, but no
new readers would be able to lock it, which I think should givbe us
enough fairness. OTOH when using _trylock new readers can still pick
the lock in read mode, and hence I think using blocking mode for
writers is actually better, as you can assure that readers won't be
able to starve writers.

Thanks, Roger.

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