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

[Julien Grall <julien@xxxxxxx>]

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?
Cheers,

--
Julien Grall

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