Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Wed, 1 May 2013 10:30:35 -0700
I will stick with my guess, though I agree that if I am correct, this situation almost certainly predates tglx's Linux-related use of frozen fish as projectile weapons. ;-) Thanx, Paul -- To unsubscr
I might hope not.. preempt_enable_no_resched() is nasty and you're likely to be hit with a frozen fish of sorts by tglx if you try to use it ;-) -- To unsubscribe from this list: send the line "unsub
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Wed, 1 May 2013 09:02:18 -0700
My guess would be for the case where sched_preempt_enable_no_resched() is followed some time later by cond_resched(). Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe lvs-deve
Good question.. at at least, only the __might_sleep() construct. Ingo, happen to remember why this is? Most of this infrastructure is from before my time. -- To unsubscribe from this list: send the l
Uhm... yes! Ah so the 'problem' with this last version is that it does an unconditional / unnessecary rcu_read_unlock(). The below would be in line with all the other cond_resched*() implementations.
BTW, I do not remember why cond_resched() is not an empty macro when CONFIG_PREEMPT=y ? -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@x
Hmm.. if that were the goal I'd like it to have a different name; cond_resched*() has always been about preemption. Quite :-) -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" i
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Wed, 1 May 2013 07:32:58 -0700
But now that I think about it, there is one big advantage to the unconditional exiting and reentering the RCU read-side critical section: It allows easy placement of unconditional lockdep debug code
Hello, You mean '#ifndef' here, right? But in the non-preempt case is using the need_resched() needed? rcu_read_unlock and rcu_read_lock do not generate code. I see. So, can we choose one of both var
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Wed, 1 May 2013 05:46:37 -0700
Good point, I was assuming that the goal was to let grace periods end as well as to allow preemption. The momentary dropping out of the RCU read-side critical section allows the grace periods to end.
OK, now I'm confused.. PREEMPT_RCU would preempt in any case, so why bother dropping rcu_read_lock() at all? That is; the thing that makes sense to me is: static void inline cond_resched_rcu_lock(voi
Hello, Yes, thanks! -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info a
Thanks, to clarify, just this: static void inline cond_resched_rcu_lock(void) { rcu_read_unlock(); cond_resched(); rcu_read_lock(); } -- To unsubscribe from this list: send the line "unsubscribe lvs-
Hello, Ops, it should be without above need_resched. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majord
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