linux-kernel - Re: [PATCH v2] kvm/x86: Inform RCU of quiescent state when entering guest mode

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]

Message-Id: <b3c188f7-454f-35da-b9aa-ddddc4d494cc@de.ibm.com>
Date:   Thu, 12 Jul 2018 13:00:45 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     David Woodhouse <dwmw2@...radead.org>, paulmck@...ux.vnet.ibm.com
Cc:     peterz@...radead.org, mhillenb@...zon.de,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v2] kvm/x86: Inform RCU of quiescent state when entering
 guest mode



On 07/12/2018 10:31 AM, David Woodhouse wrote:
> 
> 
> On Wed, 2018-07-11 at 16:47 -0700, Paul E. McKenney wrote:
>>
>>>> What changed was RCU's reactions to longish grace periods.  It used to
>>>> be very aggressive about forcing the scheduler to do otherwise-unneeded
>>>> context switches, which became a problem somewhere between v4.9 and v4.15.
>>>> I therefore reduced the number of such context switches, which in turn
>>>> caused KVM to tell RCU about quiescent states way too infrequently.
>>>  
>>> You talk about 
>>> commit bcbfdd01dce5556a952fae84ef16fd0f12525e7b
>>>      rcu: Make non-preemptive schedule be Tasks RCU quiescent state
>>>  
>>> correct? In fact, then whatever (properly sent) patch comes up should contain
>>> a fixes tag.
>>
>> Not that one, but this one is at least part of the "team":
>>
>> 28053bc72c0e5 ("rcu: Add long-term CPU kicking").  I might need to use
>> "git bisect" to find the most relevant commit...  :-/
> 
> Whichever commit we blame, I suspect the Fixes: tag wants to go on
> Paul's earlier 'Make need_resched() respond to urgent RCU-QS needs'
> patch.
> 
> The rcu_kvm_enter() thing we're talking about now is actually
> addressing a problem which has existed for much longer — that with
> NO_HZ_FULL, a CPU might end up in guest mode for an indefinite period
> of time, with RCU waiting for it to return.

On s390 this seems to add about 10ns (~3%) for a guest exit/rentry
microbenchmark mostly due to  rcu_eqs_enter and rcu_eqs_exit now being
visible in perf samples. The older interface was cheaper.