Messages in this thread | | | Date | Wed, 15 Jun 2022 16:34:08 +0530 | Subject | Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow | From | 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 >
| |