Re: [PATCH, RFC, tip/core/rcu] v3 scalable classic RCU implementation

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Sep 02, 2008 at 03:41:54PM +0200, Peter Zijlstra wrote:
> On Tue, 2008-09-02 at 09:26 -0400, Mathieu Desnoyers wrote:
> > * Peter Zijlstra (a.p.zijlstra@chello.nl) wrote:
> > > On Sat, 2008-08-30 at 07:10 -0700, Paul E. McKenney wrote:
> > > > On Sat, Aug 30, 2008 at 11:33:00AM +0200, Peter Zijlstra wrote:
> > > > > On Fri, 2008-08-29 at 17:49 -0700, Paul E. McKenney wrote:
> > > > > 
> > > > > > Some shortcomings:
> > > > > > 
> > > > > > o	Entering and leaving dynticks idle mode is a quiescent state,
> > > > > > 	but the current patch doesn't take advantage of this (noted
> > > > > > 	by Manfred).  It appears that it should be possible to make
> > > > > > 	nmi_enter() and nmi_exit() provide an in_nmi(), which would make
> > > > > > 	it possible for rcu_irq_enter() and rcu_irq_exit() to figure
> > > > > > 	out whether it is safe to tell RCU about the quiescent state --
> > > > > > 	and also greatly simplify the code.
> > > > > 
> > > > > Already done and available in the -tip tree, curtesy of Mathieu.
> > > > 
> > > > Very cool!!!  I see one of his patches at http://lkml.org/lkml/2008/4/17/342,
> > > > but how do I find out which branch of -tip this is on?  (I am learning
> > > > git, but it is a slow process...)
> > > > 
> > > > This would also simplify preemptable RCU's dyntick interface, removing
> > > > the need for proofs.
> > > 
> > > Not sure - my git-foo isn't good enough either :-(
> > > 
> > > All I can offer is that its available in tip/master (the collective
> > > merge of all of tip's branches) as commit:
> > > 0d84b78a606f1562532cd576ee8733caf5a4aed3, which I found using
> > > git-annotate include/linux/hardirq.h
> > > 
> > > How to find from which particular topic branch it came from, I too am
> > > clueless.
> > > 
> > 
> > If you're interested in knowing the topic it came from : it's required
> > so a following patch can use a "popf; ret" instead of iret to return
> > from trap handlers executed in NMI context. There is an architectural
> > problem on x86 causing NMIs to be reactivated after the first iret
> > encountered, which leads to NMI handler races if nmi handlers trap. This
> > works around the problem by returning from the trap handlers without
> > using the iret instruction.
> > 
> > It's useful to Immediate Values which put a temporary breakpoint in the
> > instruction stream when proceeding to code modification and also useful
> > to LTTng (available in the -lttng tree) which writes tracing data to
> > vmap'd memory buffers (which can cause a minor page fault).
> > 
> > I'm glad to see NMI context detection is useful to others too !
> 
> While an interesting detail, its not the answer to the question.
> 
> Given a bunch of topic branches, and a branch that has all those topic
> merged, how, for any particular commit from the merge branch, do you
> find from which topic branch it originiated?
> 
> IOW, the answer to the above question would have been a series of git
> commands that would have resulted in something like tip/tracing/nmisafe

I guess that it turned out that there was a series of mutt commands that
eventually got the answer.  That said, a series of git commands would
be quite nice.  ;-)

But it would appear that the series of git commands would need to come
from someone with better git-foo than either Mathieu or myself.  :-/

							Thanx, Paul