lkml.org 
[lkml]   [2008]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH, RFC, tip/core/rcu] v3 scalable classic RCU implementation
    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


    \
     
     \ /
      Last update: 2008-09-02 16:57    [W:2.355 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site