Re: [Xen-devel] [PATCH v2 0/4] xen/rcu: let rcu work better with core scheduling

[Jürgen Groß <jgross@xxxxxxxx>]

On 22.02.20 13:32, Julien Grall wrote:
> Hi,
>
> On 22/02/2020 06:05, Jürgen Groß wrote:
> > On 22.02.20 03:29, Igor Druzhinin wrote:
> > > On 18/02/2020 12:21, Juergen Gross wrote:
> > > > Today the RCU handling in Xen is affecting scheduling in several ways.
> > > > It is raising sched softirqs without any real need and it requires
> > > > tasklets for rcu_barrier(), which interacts badly with core scheduling.
> > > >
> > > > This small series repairs those issues.
> > > >
> > > > Additionally some ASSERT()s are added for verification of sane rcu
> > > > handling. In order to avoid those triggering right away the obvious
> > > > violations are fixed.
> > > I've done more testing of this with [1] and, unfortunately, it quite 
> > > easily
> > > deadlocks while without this series it doesn't.
> > >
> > > Steps to repro:
> > > - apply [1]
> > > - take a host with considerable CPU count (~64)
> > > - run a loop: xen-hptool smt-disable; xen-hptool smt-enable
> > >
> > > [1] 
> > > https://lists.xenproject.org/archives/html/xen-devel/2020-02/msg01383.html 
> > Yeah, the reason for that is that rcu_barrier() is a nop in this
> > situation without my patch, as the then called stop_machine_run() in
> > rcu_barrier() will just return -EBUSY.
> I think rcu_barrier() been a NOP is also problem as it means you would 
> be able to continue before the in-flight callback has been completed.
> But I am not entirely sure why a deadlock would happen with your 
> suggestion? Could you details a bit more?
get_cpu_maps() will return false as long stop_machine_run() is holding
the lock, and rcu handling will loop until it gets the lock...


Juergen

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