[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJhGHyALnn2EmPDXS3hyt1sgTH8vu=yeLo+N5meg7PZg7WrFQw@mail.gmail.com>
Date: Fri, 22 Oct 2021 12:11:55 +0800
From: Lai Jiangshan <jiangshanlai+lkml@...il.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
Davidlohr Bueso <dave@...olabs.net>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Wanpeng Li <wanpengli@...cent.com>
Subject: Re: [PATCH] rcuwait: do not enter RCU protection unless a wakeup is needed
On Wed, Oct 20, 2021 at 7:39 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On 20/10/21 13:17, Peter Zijlstra wrote:
> > AFAICT, rcu_read_lock() for PREEMPT_RCU is:
> >
> > WRITE_ONCE(current->rcu_read_lock_nesting, READ_ONCE(current->rcu_read_lock_nesting) + 1);
> > barrier();
>
> rcu_read_unlock() is the expensive one if you need to go down
> rcu_read_unlock_special().
>
If "actual likelihood of a wakeup is very low." as stated in the changelog,
the likelihood of rcu_read_unlock_special() is also very low.
rcu_read_lock() for PREEMPT_RCU is a function call, is it relevant?
(It is possible to remove the function call if the include-hell can
be resolved or remove the function call via LTO or just remove the
function call in X86 via percpu.)
Thanks
Lai
> Paolo
>
> > Paul?
>
Powered by blists - more mailing lists