powerpc: Add rcu_read_lock() to gup_fast() implementation
in [Kernel]
|
From: Benjamin Herrenschmidt on 16 Apr 2010 03:00 On Mon, 2010-04-12 at 20:43 -0700, Paul E. McKenney wrote: > > So we might have to support the interrupt assumption, at least in > some > > form, with those guys... > > One way to make the interrupt assumption official is to use > synchronize_sched() rather than synchronize_rcu(). Ok, so I'm a bit of a RCU newbie as you may know :-) Right now, we use neither, we use call_rcu and we free the pages from the callback. 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: Benjamin Herrenschmidt on 16 Apr 2010 03:30 On Thu, 2010-04-15 at 07:28 -0700, Paul E. McKenney wrote: > > Of course, with call_rcu_sched(), the corresponding RCU read-side > critical > sections are non-preemptible. Therefore, in CONFIG_PREEMPT_RT, these > read-side critical sections must use raw spinlocks. > > Can the code in question accommodate these restrictions? What we protect against is always code that hard-disable IRQs (though there seem to be a bug in the hugepages code there...). Would that work ? 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: Nick Piggin on 16 Apr 2010 04:20 On Fri, Apr 16, 2010 at 04:51:34PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2010-04-12 at 20:43 -0700, Paul E. McKenney wrote: > > > So we might have to support the interrupt assumption, at least in > > some > > > form, with those guys... > > > > One way to make the interrupt assumption official is to use > > synchronize_sched() rather than synchronize_rcu(). > > Ok, so I'm a bit of a RCU newbie as you may know :-) Right now, we use > neither, we use call_rcu and we free the pages from the callback. BTW. you currently have an interesting page table freeing path where you usually free by RCU, but (occasionally) free by IPI. This means you need to disable both RCU and interrupts to walk page tables. If you change it to always use RCU, then you wouldn't need to disable interrupts. Whether this actually matters anywhere in your mm code, I don't know (it's probably not terribly important for gup_fast). But rcu disable is always preferable for latency and performance. -- 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 04:40 On Fri, 2010-04-16 at 18:18 +1000, Nick Piggin wrote: > On Fri, Apr 16, 2010 at 04:51:34PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2010-04-12 at 20:43 -0700, Paul E. McKenney wrote: > > > > So we might have to support the interrupt assumption, at least in > > > some > > > > form, with those guys... > > > > > > One way to make the interrupt assumption official is to use > > > synchronize_sched() rather than synchronize_rcu(). > > > > Ok, so I'm a bit of a RCU newbie as you may know :-) Right now, we use > > neither, we use call_rcu and we free the pages from the callback. > > BTW. you currently have an interesting page table freeing path where > you usually free by RCU, but (occasionally) free by IPI. This means > you need to disable both RCU and interrupts to walk page tables. Well, the point is we use interrupts to synchronize. The fact that RCU used to do the job was an added benefit. I may need to switch to rcu _sched variants tho to keep that. The IPI case is a slow path in case we are out of memory and cannot allocate our page of RCU batch. > If you change it to always use RCU, then you wouldn't need to disable > interrupts. Whether this actually matters anywhere in your mm code, I > don't know (it's probably not terribly important for gup_fast). But > rcu disable is always preferable for latency and performance. Well, the main case is the hash miss and that always runs with IRQs off. Cheers, Ben. > -- > To unsubscribe from this list: send the line "unsubscribe linux-arch" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Nick Piggin on 16 Apr 2010 05:30 On Fri, Apr 16, 2010 at 06:29:02PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-04-16 at 18:18 +1000, Nick Piggin wrote: > > On Fri, Apr 16, 2010 at 04:51:34PM +1000, Benjamin Herrenschmidt wrote: > > > On Mon, 2010-04-12 at 20:43 -0700, Paul E. McKenney wrote: > > > > > So we might have to support the interrupt assumption, at least in > > > > some > > > > > form, with those guys... > > > > > > > > One way to make the interrupt assumption official is to use > > > > synchronize_sched() rather than synchronize_rcu(). > > > > > > Ok, so I'm a bit of a RCU newbie as you may know :-) Right now, we use > > > neither, we use call_rcu and we free the pages from the callback. > > > > BTW. you currently have an interesting page table freeing path where > > you usually free by RCU, but (occasionally) free by IPI. This means > > you need to disable both RCU and interrupts to walk page tables. > > Well, the point is we use interrupts to synchronize. The fact that RCU > used to do the job was an added benefit. I may need to switch to rcu > _sched variants tho to keep that. The IPI case is a slow path in case we > are out of memory and cannot allocate our page of RCU batch. It is the slowpath but it forces all lookup paths to do irq disable too. > > If you change it to always use RCU, then you wouldn't need to disable > > interrupts. Whether this actually matters anywhere in your mm code, I > > don't know (it's probably not terribly important for gup_fast). But > > rcu disable is always preferable for latency and performance. > > Well, the main case is the hash miss and that always runs with IRQs off. Probably not a big deal then. -- 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
|
Next
|
Last
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 |