Messages in this thread | | | Date | Sat, 17 Nov 2007 23:36:26 -0600 | From | Don Porter <> | Subject | Re: [RFC/PATCH] Optimize zone allocator synchronization |
| |
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: > It's funny, Dave Miller and I were just talking about the possible > reappearance of zone->lock contention with massively multi core and > multi threaded CPUs. I think the right way to fix this in the long run > if it turns into a real problem, is something like having a lock per > MAX_ORDER block, and having CPUs prefer to allocate from different > blocks. Anti-frag makes this pretty interesting to implement, but it > will be possible.
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 - 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/
| |