site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com

...

I know, I could take the hit and use a spinlock for those buffers, but depending on the configuration Lustre can log a lot of data and doing that could really hurt performance

Instead of taking a spinlock, can you consider using atomic increment (locked cmpxchg) to update the index into the buffer. This worked very well for me in the past for similar requirements.

Okay, I think I understand ... via OSAddAtomic() or similar function? Yeah, I got it ... that returns the original value, so you'd add the value of what you'd want to log to a buffer pointer via OSAddAtomic and store it at the offset returned by OSAddAtomic().

The thread writing at the end of the buffer and wraping around may have to do atomic increment twice depending on your implementation.You don't even need to disable preemption(assuming that size of data written by all threads simultaneously to this buffer is not greater than size of the buffer).

Alright, I think I can see how to do it with wraparound safely. This code in Lustre that handles all of this is rather complicated, and it really deals with a collection of pages and handles them on a per-page basis, rather than dealing with a single buffer. I was just hoping to do the minimal amount of work possible to port this code, but at least if I write a new set of debugging routines it should be pretty isolated from the rest of Lustre. Admittedly the situation isn't ideal. Sigh. --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com