Messages in this thread | | | Date | Mon, 14 Oct 2013 18:01:21 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 0/6] Optimize the cpu hotplug locking -v2 |
| |
On Mon, Oct 14, 2013 at 02:23:55AM -0700, Paul E. McKenney wrote: > On Mon, Oct 14, 2013 at 11:05:08AM +0200, Peter Zijlstra wrote: > > On Sat, Oct 12, 2013 at 07:06:56PM +0200, Oleg Nesterov wrote: > > > it even disables irqs, so this should always imply rcu_read_lock() with > > > any implementation, > > > > Not so; I could make an RCU implementation that drives the state machine > > from rcu_read_unlock(). Such an implementation doesn't need the > > interrupt driven poll-state driver we currently have and could thus > > subvert that assumption :-) > > > > Then again, there's a good reason PaulMck didn't pick this > > implementation. > > True enough, but there really are some out-of-tree RCU implementations > that do take this approach and where disabling interrupts would not > block preemptible RCU. So please do not rely on this implementation > detail. You never know...
Actually, the current implementation of SRCU is not blocked by CPUs disabling interrupts!
Thanx, Paul
> > > In fact I do not even understand why getaffinity() doesn't simply > > > return ->cpus_allowed, but this is off-topic. > > > > Yeah, me neither :-(, it always surprises me. But changing it is likely > > to break stuff so there we are. > > I know that feeling... > > Thanx, Paul
| |