lkml.org 
[lkml]   [2004]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][5/8] Arch agnostic completely out of line locks / ppc64
    Hello Paul,

    On Thu, 9 Sep 2004, Paul Mackerras wrote:

    > Just got a chance to look at the new out-of-line spinlock stuff
    > (better late than never :). I see a couple of problems there. First,
    > we now go two levels deep on SMP && PREEMPT: spin_lock is _spin_lock,
    > which is out of line in kernel/sched.c. That calls
    > __preempt_spin_lock, which is out of line in kernel/sched.c, and isn't
    > in the .text.lock section. So if we get a timer interrupt in there,
    > we won't attribute the profile tick to the original caller.

    I think that bit is actually intentional since __preempt_spin_lock is also
    marked __sched so that it'll get charged as a scheduling function.

    > The second problem is that __preempt_spin_lock doesn't do the yield to
    > the hypervisor which we need to do on shared processor systems. This
    > is actually a long-standing problem, not one you have just introduced,
    > but I have only just noticed it. I can't make cpu_relax do the yield
    > because the yield is a directed yield to a specific other virtual cpu
    > (it says "give the rest of my timeslice to that guy over there") and I
    > need the value in the lock variable in order to know who is holding
    > the lock.

    I think cpu_relax() (or some other primitive) should actually take a
    parameter, this will allow for us to use monitor/mwait on i386 too so
    that in cases where we're spinning waiting on memory modify we could do
    something akin to the following;

    while (spin_is_locked(lock))
    cpu_relax(lock);

    Although there are wakeup latencies when using monitor/mwait for such,
    some cases such as above should be ok (although there are implementation
    details such as the cost of a monitor operation on things like spin
    unlock paths). I believe such an API modification would be beneficiel for
    you too. What do others think?

    Thanks,
    Zwane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:3.823 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site