Messages in this thread | | | Date | Wed, 15 Jun 2022 12:50:14 +0200 | Subject | Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow | From | Paolo Bonzini <> |
| |
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?
Thanks,
Paolo
| |