Re: cpu_number()
Re: cpu_number()
- Subject: Re: cpu_number()
- From: Ken Hornstein <email@hidden>
- Date: Fri, 19 Aug 2011 14:18:43 -0400
>> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden