From: Paul McKenney <Paul.McK<enney@us...> - 2000-12-24 04:45:47
Thank you for looking this over! Do you feel read-copy update would be of
interest at Ottawa?
> On Thu, Dec 21, 2000 at 01:25:42PM -0800, Paul McKenney wrote:
> > I believe that read-copy update will be very helpful to increase
> > ability to scale, while also keeping Linux's great single-CPU
> > Thoughts?
> Thanks a lot for these references. I have not 100% digested your paper
> yet, but it looks very useful so far. A few datastructures
> in Linux come immediately to mind where this approach could help a lot:
> e.g. Linux 2.4 networking and VFS have developed far too many reference
> counters in the recent SMP work, causing lots of locked cycles because
> these need to be updated atomically. Another very ugly problem where it
> could be used is the module unload problem: with the drop of the big
> lock module unloading and kernel code often runs completely
> which causes lots of interesting races (the current fixes is adding even
> more reference counters and even module pointers to all kind of shared
> objects, slow and ugly). It would be very exciting to clean all that mess
Thank you very much for the pointers! We will spend some time looking
in these areas! Please let me know which parts of the paper are difficult,
I know it could stand some improvement.
> Linux did go a bit in this direction already with the big-reader locks
> (see include/linux/brlock.h in a 2.4 tree). We also considered
> schemes for really infrequent events (like the change of the ip protocol
> but forgot it because on big CPU systems it is possible that such an
> would never succeed.
> The quiescent state approach looks much better than the brlocks of
The brlock approach certainly has its place due to the ability of writers
to block readers. But I agree that read-copy update is nicer where it
Of course I freely admit to the possibility of prejudice! ;-)