lkml.org 
[lkml]   [2022]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow
From
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

\
 
 \ /
  Last update: 2022-06-15 12:51    [W:0.098 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site