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

From: bob (
Date: Sun Sep 22 2002 - 17:52:19 EST

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
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

This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:37 EST