Re: [ltt-dev] Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure

[bob <bob@watson.ibm.com>]

Ingo Molnar writes:
 > 
 > On Sun, 22 Sep 2002, bob wrote:
 > 
 > > > (this is in essence a moving spinlock at the tail of the trace buffer -
 > > > same problem.)
 > > 
 > > No, we use lock-free atomic operations to reserve a place in the buffer
 > > to write the data.  What happens is you attempt to atomic move the
 > > current index pointer forward.  If you succeed then you have bought
 > > yourself that many data words in the queue.  In the unlikely event you
 > > happened to collide with someone you perform the atomic operation again.
 > 
 > you have not understood what i have written.
 > 
 > what you do has the same (bad) effect as a global spinlock, it in essence
 > has the same cache effect as a constantly moving spinlock at the 'end' of
 > the trace buffer. Cachelines bounce between CPUs. Only completely per-CPU
 > trace buffers solve this problem.

As per previous email, we are moving to a per-CPU scheme.  On a technical
note: a cache-line ping-ponging is bad - a global spinlock is horrendous.
They're different - the lock-less MP scheme gets rid of them both.

>  - do not disable interrupts when writing events. I used this method in
>    a tracer and it works well. Just get an irq-safe index to the trace
>    ring-buffer and fill it in. [eg. on x86 incl can be used for this
>    purpose.]

The lock-less scheme does not disable interrupts - we've eliminated that.

Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com