powerpc: Add rcu_read_lock() to gup_fast() implementation
in [Kernel]
|
From: Paul E. McKenney on 16 Apr 2010 16:30 On Fri, Apr 16, 2010 at 09:37:02PM +0200, Peter Zijlstra wrote: > On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote: > > o mutex_lock(): Critical sections need not guarantee > > forward progress, as general blocking is permitted. > > > Right, I would argue that they should guarantee fwd progress, but due to > being able to schedule while holding them, its harder to enforce. > > Anything that is waiting for uncertainty should do so without any locks > held and simply re-acquire them once such an event does occur. Agreed. But holding a small-scope mutex for (say) 60 seconds would not be a problem (at 120 seconds, you might start seeing softlockup messages). In contrast, holding off an RCU grace period for 60 seconds might well OOM the machine, especially a small embedded system with limited memory. > > So the easy response is "just use SRCU." Of course, SRCU has some > > disadvantages at the moment: > > > > o The return value from srcu_read_lock() must be passed to > > srcu_read_unlock(). I believe that I can fix this. > > > > o There is no call_srcu(). I believe that I can fix this. > > > > o SRCU uses a flat per-CPU counter scheme that is not particularly > > scalable. I believe that I can fix this. > > > > o SRCU's current implementation makes it almost impossible to > > implement priority boosting. I believe that I can fix this. > > > > o SRCU requires explicit initialization of the underlying > > srcu_struct. Unfortunately, I don't see a reasonable way > > around this. Not yet, anyway. > > > > So, is there anything else that you don't like about SRCU? > > No, I quite like SRCU when implemented as preemptible tree RCU, and I > don't at all mind that last point, all dynamic things need some sort of > init. All locks certainly have. Very good!!! I should clarify, though -- by "explicit initialization", I mean that there needs to be a run-time call to init_srcu_struct(). Unless there is some clever way to initialize an array of pointers to per-CPU structures at compile time. And, conversely, a way to initialize pointers in a per-CPU structure to point to possibly-different rcu_node structures. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 16 Apr 2010 19:30 On Fri, 2010-04-16 at 06:43 -0700, Paul E. McKenney wrote: > So I believe that in this case call_rcu_sched() is your friend. ;-) Looks like it :-) I'll cook up a patch changing my current call_rcu() to call_rcu_sched(). Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 17 Apr 2010 23:10 On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote: > o mutex_lock(): Critical sections need not guarantee > forward progress, as general blocking is permitted. This isn't quite right. mutex critical sections must guarantee eventual forward progress against the class of other potential acquirers of the mutex otherwise the system will become either deadlocked or livelocked. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 18 Apr 2010 10:00 On Sat, Apr 17, 2010 at 10:06:36PM -0500, James Bottomley wrote: > On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote: > > o mutex_lock(): Critical sections need not guarantee > > forward progress, as general blocking is permitted. > > This isn't quite right. mutex critical sections must guarantee eventual > forward progress against the class of other potential acquirers of the > mutex otherwise the system will become either deadlocked or livelocked. If I understand you correctly, you are saying that it is OK for a given critical section for a given mutex to fail to make forward progress if nothing else happens to acquire that mutex during that time. I would agree, at least I would if you were to further add that the soft-lockup checks permit an additional 120 seconds of failure to make forward progress even if something -is- attempting to acquire that mutex. By my standards, 120 seconds is a reasonable approximation to infinity, hence my statement above. So, would you agree with the following as a more precise statement? o mutex_lock(): Critical sections need not guarantee forward progress unless some other task is waiting on the mutex in question, in which case critical sections should complete in 120 seconds. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 18 Apr 2010 15:00 On Sun, 2010-04-18 at 06:55 -0700, Paul E. McKenney wrote: > On Sat, Apr 17, 2010 at 10:06:36PM -0500, James Bottomley wrote: > > On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote: > > > o mutex_lock(): Critical sections need not guarantee > > > forward progress, as general blocking is permitted. > > > > This isn't quite right. mutex critical sections must guarantee eventual > > forward progress against the class of other potential acquirers of the > > mutex otherwise the system will become either deadlocked or livelocked. > > If I understand you correctly, you are saying that it is OK for a given > critical section for a given mutex to fail to make forward progress if > nothing else happens to acquire that mutex during that time. I would > agree, at least I would if you were to further add that the soft-lockup > checks permit an additional 120 seconds of failure to make forward progress > even if something -is- attempting to acquire that mutex. Yes ... I was thinking of two specific cases: one is wrong programming of lock acquisition where the system deadlocks; the other is doing silly things like taking a mutex around an event loop instead of inside it so incoming events prevent forward progress and the system livelocks, but there are many other ways of producing deadlocks and livelocks. I just couldn't think of a concise way of saying all of that but I didn't want a statement about mutexes to give the impression that anything goes. I've got to say that I also dislike seeing any form of sleep within a critical section because it's just asking for a nasty entangled deadlock which can be very hard to sort out. So I also didn't like the statement "general blocking is permitted" > By my standards, 120 seconds is a reasonable approximation to infinity, > hence my statement above. > > So, would you agree with the following as a more precise statement? > > o mutex_lock(): Critical sections need not guarantee > forward progress unless some other task is waiting > on the mutex in question, in which case critical sections > should complete in 120 seconds. Sounds fair. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: 2.6.34-rc3-git8: Reported regressions 2.6.32 -> 2.6.33 Next: mm: Preemptible mmu_gather |