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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Jun 2022 16:34:08 +0530
From:   Neeraj Upadhyay <quic_neeraju@...cinc.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "zhangfei.gao@...mail.com" <zhangfei.gao@...mail.com>,
        <paulmck@...nel.org>, zhangfei <zhangfei.gao@...aro.org>
CC:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Josh Triplett <josh@...htriplett.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Matthew Wilcox <willy@...radead.org>,
        "mtosatti@...hat.com" <mtosatti@...hat.com>,
        Auger Eric <eric.auger@...hat.com>,
        "chenxiang (M)" <chenxiang66@...ilicon.com>
Subject: Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking
 readers from consuming CPU) cause qemu boot slow



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
>