[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180626170812.GH2494@hirez.programming.kicks-ass.net>
Date: Tue, 26 Jun 2018 19:08:12 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
oleg@...hat.com, joel@...lfernandes.org
Subject: Re: [PATCH tip/core/rcu 06/27] rcu: Mark task as .need_qs less
aggressively
On Mon, Jun 25, 2018 at 05:34:52PM -0700, Paul E. McKenney wrote:
> If any scheduling-clock interrupt interrupts an RCU-preempt read-side
> critical section, the interrupted task's ->rcu_read_unlock_special.b.need_qs
> field is set. This causes the outermost rcu_read_unlock() to incur the
> extra overhead of calling into rcu_read_unlock_special(). This commit
> reduces that overhead by setting ->rcu_read_unlock_special.b.need_qs only
> if the grace period has been in effect for more than one second.
Even less agressive is never setting it at all.
Changelog fails to explain why not setting it every tick is correct, nor
why 1s is a 'safe' value to use.
Powered by blists - more mailing lists