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

bob
2002-09-22T22:47:27Z

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