lkml.org 
[lkml]   [2007]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BUG] long freezes on thinkpad t60
    Linus Torvalds wrote:
    > Nick,
    > call me a worry-wart, but I slept on this, and started worrying..
    >
    > On Tue, 26 Jun 2007, Linus Torvalds wrote:
    >
    >>So try it with just a byte counter, and test some stupid micro-benchmark
    >>on both a P4 and a Core 2 Duo, and if it's in the noise, maybe we can make
    >>it the normal spinlock sequence just because it isn't noticeably slower.
    >
    >
    > So I thought about this a bit more, and I like your sequence counter
    > approach, but it still worried me.
    >
    > In the current spinlock code, we have a very simple setup for a
    > successful grab of the spinlock:
    >
    > CPU#0 CPU#1
    ...

    Yeah, thanks.

    > Now, I have good reason to believe that all Intel and AMD CPU's have a
    > stricter-than-documented memory ordering, and that your spinlock may
    > actually work perfectly well. But it still worries me. As far as I can
    > tell, there's a theoretical problem with your spinlock implementation.
    >
    > So I'd like you to ask around some CPU people, and get people from both
    > Intel and AMD to sign off on your spinlocks as safe. I suspect you already
    > have the required contacts, but if you don't, I can send things off to the
    > appropriate people at least inside Intel.

    Haven't made too much progress on this, but I have asked someone@amd who
    might be able to at least know the right person to ask :P (might be faster
    to ask Andi to ask :))

    If you know someone at Intel then that would be appreciated.

    It would be nice if it is safe (and can be guaranteed to be safe in future).

    However OTOH, the fastpath may be even faster if we do it in a "definitely
    safe" way.

    That is, do the xaddw against 16-bits with the head in 8 of those and the
    tail in the other 8. Then compare the byte registers of the register
    returned by xaddw for the test. Although the xaddw is going to be slower
    than an xaddb, this way we subsequently avoid the extra load completely,
    while avoiding ordering issues.

    In the slowpath we would have to have a token locked op in there (like
    the current spinlocks do), but this could be taken out iff our inquiries
    come back positive.

    Anyway, I'll try redoing the patch and getting some numbers.

    --
    SUSE Labs, Novell Inc.
    -
    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: 2007-07-02 09:09    [W:4.344 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site