Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow

[Neeraj Upadhyay]

On 6/15/2022 4:20 PM, Paolo Bonzini wrote:
> On 6/15/22 12:40, Neeraj Upadhyay wrote:
> > This is useful data, thanks! Did you get chance to check between 100 
> > and 1000, to narrow down further, from which point (does need to be 
> > exact value) between 100 and 1000,  you start seeing degradation at, 
> > for ex. 250, 500 , ...?
> >
> > Is it also possible to try experiment 10 and 11 with below diff.
> > What I have done in below diff is, call srcu_get_delay() only once
> > in try_check_zero() (and not for every loop iteration); also
> > retry with a different delay for the extra iteration which is done
> > when srcu_get_delay(ssp) returns 0.
> >
> > Once we have this data, can you also try by changing 
> > SRCU_RETRY_CHECK_LONG_DELAY   to 100, on top of below diff.
> >
> > #define SRCU_RETRY_CHECK_LONG_DELAY  100
>
> Is there any data that you would like me to gather from the KVM side, 
> for example with respect to how much it takes to do synchronize_srcu() 
> on an unpatched kernel, or the duration of the read-sides?

Hi Paolo,

Thanks! I think synchronize_srcu() time and read side duration will 
help. Given that changing SRCU_MAX_NODELAY_PHASE value has impact
on the boot time (and SRCU_MAX_NODELAY_PHASE impact is dependent on 
duration of SRCU read side duration), this information will be helpful 
to get more understanding of the scenario.


Thanks
Neeraj

> Thanks,
>
> Paolo