On Thu, 2012-05-17 at 08:47 -0700, Paul E. McKenney wrote: > On Thu, May 17, 2012 at 05:32:59PM +0200, Peter Zijlstra wrote: > > On Thu, 2012-05-17 at 08:18 -0700, Paul E. McKenney wrote: > > > Some researchers at MIT RCU-ified this lock: > > > > > > http://people.csail.mit.edu/nickolai/papers/clements-bonsai.pdf > > > > Ah, as have I [1].. and they seem to have gotten about as far as I have, > > which means almost there but not quite [2] :-) > > I had forgotten about that -- that was the first call for call_srcu(), > if I remember correctly. > > > The most interesting case is file maps and they simply ignored those. > > While I appreciate that from an academic pov, -- they can still write a > > paper on the other interesting bits -- I don't really like it from a > > practical point. > > > > [1] https://lkml.org/lkml/2010/1/4/257 > > [2] https://lkml.org/lkml/2010/1/4/532 > > Hmmm... Do the recent dcache changes cover some of the things that > Linus called out? Probably not, but some at least. No, and the points viro made: https://lkml.org/lkml/2010/1/5/194 are still very much an issue, you really don't want to do fput() from an asynchronous context. Which means you have to do synchronize_rcu() or similar from munmap() which will be rather unpopular :/ Since we should not use per-cpu data for either files or processes (there are simply too many of those around) the alternative is horrendously hideous things like: https://lkml.org/lkml/2010/1/6/136 which one cannot get away with either. The whole thing is very vexing indeed since all of this is only needed for ill-behaved applications since a well-constructed application will never fault in a range it is concurrently unmapping. Most annoying. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
