Thank you all for your consideration and insightful responses to my
posting. I apologize for not responding sooner---I have been under a
deadline.
It seems clear that further investigation will be needed to understand
these performance numbers better.
To summarize, I understand that the following experiments will be helpful:
1) Instrument the allocation code to determine the common size/order
of the allocations for these workloads.
2) Try to integrate these changes with ticket spinlocks
3) Try placing the zone lock in its own cacheline
4) Look for single-threaded regressions (dd benchmark).
I'll do these at my first opportunity, hopefully within the next week.
Please let me know if I misunderstood any of your comments.
My intuition about the cost of ping-ponging the lock's cache line
certainly matched yours, so I was very surprised to see these
performance numbers.
On Wed, Nov 07, 2007 at 04:31:59PM +1100, Nick Piggin wrote:
As a bit of background, the zone lock is indeed one of the more
contended locks in my target workloads so it was no accident that I
was looking for ways to improve its scalability. I am quite
interested in Nick's ideas about how to split up the zone allocator's
synchronization.
Of course, these contention levels may not meet your definition of
"real problem" (~.1% of the execution time).
Best regards,
Don
-
