[lkml]   [2002]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ltt-dev] Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure

    On Sun, 22 Sep 2002, bob wrote:

    > However, for sake of argument, the above is still not true. A global
    > lock has a different (worse) performance problem then the lock-free
    > atomic operation even given a global queue. The difference is 1) the
    > Linux global lock is very expensive [... and interacts with potential
    > other processes, [...]

    huh? what is 'the Linux global lock'?

    > [...] and 2) you have to hold the lock for the entire duration of
    > logging the event; with the atomic operation you are finished once
    > you've reserved you space. [...]

    you dont have to hold the lock for the duration of saving the event, the
    lock could as well protect a 'current entry' index. (Not that those 2-3
    cycles saving off the event into a single cacheline counts that much ...)

    the tail-atomic method is precisely equivalent to a global spinlock. The
    tail of a global event buffer acts precisely as a global spinlock: if one
    CPU writes to it in a stream then it performs okay, if two CPUs trace in
    parallel then it causes cachelines to bounce like crazy.

    > [...] If you didn't use the expensive Linux global lock and just a
    > global lock, you could be interrupted in the middle of holding the lock
    > and performance would fall off the map.

    again, what 'expensive Linux global lock' are you talking about?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.019 / U:393.864 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site