Messages in this thread | | | From | bob <> | Date | Sun, 22 Sep 2002 18:52:19 -0400 (EDT) | Subject | Re: [ltt-dev] Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure |
| |
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 - 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/
| |