Re: [PATCH ipvs-next v3 1/2] sched: add cond_resched_rcu() helper

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [PATCH ipvs-next v3 1/2] sched: add cond_resched_rcu() helper
Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>, Julian Anastasov <ja@xxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Dipankar Sarma <dipankar@xxxxxxxxxx>
From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Date: Thu, 23 May 2013 13:30:19 +0200
On Wed, May 22, 2013 at 02:50:31PM +0900, Simon Horman wrote:
> This is intended for use in loops which read data protected by RCU and may
> have a large number of iterations.  Such an example is dumping the list of
> connections known to IPVS: ip_vs_conn_array() and ip_vs_conn_seq_next().
> The benefits are for CONFIG_PREEMPT_RCU=y where we save CPU cycles
> by moving rcu_read_lock and rcu_read_unlock out of large loops
> but still allowing the current task to be preempted after every
> loop iteration for the CONFIG_PREEMPT_RCU=n case.
> The call to cond_resched() is not needed when CONFIG_PREEMPT_RCU=y.
> Thanks to Paul E. McKenney for explaining this and for the
> final version that checks the context with CONFIG_DEBUG_ATOMIC_SLEEP=y
> for all possible configurations.
> The function can be empty in the CONFIG_PREEMPT_RCU case,
> rcu_read_lock and rcu_read_unlock are not needed in this case
> because the task can be preempted on indication from scheduler.
> Thanks to Peter Zijlstra for catching this and for his help
> in trying a solution that changes __might_sleep.
> Initial cond_resched_rcu_lock() function suggested by Eric Dumazet.

Applied, thanks.
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>