Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Sat, 4 May 2013 11:03:16 -0700
Very good! Please send the patch along, and I will ack it. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx Mo
Hello, Works perfectly. Thanks! Tested CONFIG_PREEMPT_RCU=y/n, the errors messages with extra RCU lock. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubs
Oh argh.. I completely overlooked that rcu_read_{,un}lock() are NOPs for PREEMPT=n kernels. /me crawls back under his stone.. -- To unsubscribe from this list: send the line "unsubscribe lvs-devel"
Hello, It should work. It is a better version of the 2nd variant I mentioned here: http://marc.info/?l=linux-netdev&m=136741839021257&w=2 I'll stick to this version, hope Peter Zijlstra agrees. Playi
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Fri, 3 May 2013 10:34:44 -0700
This happens in only two cases: 1. CONFIG_PREEMPT_RCU=n kernels. But in this case, rcu_read_unlock() and rcu_read_lock() are free, at least for CONFIG_PROVE_LOCKING=n kernels. And if you have CONFIG_
It can do quite a number of superfluous rcu_read_unlock()/lock() pairs for voluntary preemption kernels? -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a mess
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Fri, 3 May 2013 09:30:45 -0700
OK, after getting some sleep, I might have located the root cause of my confusion yesterday. The key point is that I don't understand why we cannot get the effect we are looking for with the followin
Hello, In this case when CONFIG_PREEMPT_RCU is enabled we (RCU) do not touch the preempt counters. Instead, the units are accounted in current->rcu_read_lock_nesting: __rcu_read_lock: current->rcu_re
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Thu, 2 May 2013 15:31:07 -0700
OK, apologies -- I was looking at the calls to __might_sleep() in mainline, and missed the one that you added. Revisiting that, a question: Does this really want to be "1" instead of PREEMPT_OFFSET?
Hello, Yes, the different platforms use different bit, that is why I mentioned about my failed attempt at changing hardirq.h. PREEMPT_ACTIVE is always != 0. But I don't understand what do you mean by
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Thu, 2 May 2013 12:34:09 -0700
OK... PREEMPT_ACTIVE's value is usually 0x10000000. Did it change since 3.9? If not, rcu_sleep_check(preempt_offset & PREEMPT_ACTIVE) is the same as rcu_sleep_check(0). Thanx, Paul -- To unsubscribe
Hello, Just to clarify about the test with extra rcu_read_lock because above paragraph is very confusing: - The __might_sleep call with PREEMPT_ACTIVE | PREEMPT_RCU_OFFSET just warns with "BUG: sleep
Hello, Note that I'm testing on some 9-year old UP system, i.e. 1 CPU. Now I enabled SMP to test CONFIG_TREE_RCU and the results are same. I think, it should be just like the TINY_RCU in terms of the
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Thu, 2 May 2013 10:32:57 -0700
Could you please also try CONFIG_TREE_RCU? Color me confused. are PREEMPT_LOCK_OFFSET and SOFTIRQ_DISABLE_OFFSET. PREEMPT_ACTIVE is normally a high-order bit, above PREEMPT_MASK, SOFTIRQ_MASK, and HA
Hello, I implemented your idea. I tested the following patch in 2 variants, TINY_RCU and CONFIG_TREE_PREEMPT_RCU. I see the error if extra rcu_read_lock is added for testing. I'm using the PREEMPT_AC
Hello, Looks like CONFIG_DEBUG_ATOMIC_SLEEP selects CONFIG_PREEMPT_COUNT, so PREEMPT_RCU_OFFSET should be 1 in all cases because preempt_disable() adds 1, while for CONFIG_PREEMPT_RCU case rcu_preemp
The __might_sleep(__FILE__, __LINE__, PREEMPT_RCU_OFFSET) I posted in the other email just now should deal with this. -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the bo
__might_sleep(__FILE__, __LINE__, PREEMPT_RCU_OFFSET); \ __cond_resched_rcu(); \ }) Should work I think.. -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a mess
Author: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Date: Wed, 1 May 2013 12:04:12 -0700
The above requires that include/linux/sched.h be included. This might be OK, but please check the current intended uses. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe lvs-d
Hello, It is just a barrier() for the non-preempt case. ... I see your goal. But digging into __might_sleep() I see that rcu_sleep_check() will scream for the non-preempt case because we are under rc