In article <1022609447.4123.126.camel@irongate.swansea.linux.org.uk> Alan Cox wrote:
> On Tue, 2002-05-28 at 17:34, Andi Kleen wrote:
>> And gain tons of new atomic_incs and decs everywhere in the process?
>> I would prefer RCU.
> Lots of people write drivers, many of them not SMP kernel locking gurus
> who have time to understand RCU and when they can or cannot sleep, and
> what happens if their unload is pre-empted and RCU is in use. The kernel
> core has to provide a clean easy interface. The network code is a superb
> example of this. All the hard thinking is done outside of the driver, at
> least unless you choose to join in that thinking to get the last scraps
> of performance.
FWIW, recent RCU implementations support preemption. synchronize_kernel()
in rcu_poll_preempt patches use call_rcu_preempt() where callbacks
wait until all CPUs have done a voluntary context switch.
See http://prdownloads.sourceforge.net/lse/rcu_poll_preempt-2.5.14-2.patch
Thanks
-- Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/