On 02/04/2018 09:31 PM, Aaron Lu wrote: > Running will-it-scale/page_fault1 process mode workload on a 2 sockets > Intel Skylake server showed severe lock contention of zone->lock, as > high as about 80%(43% on allocation path and 38% on free path) CPU > cycles are burnt spinning. With perf, the most time consuming part inside > that lock on free path is cache missing on page structures, mostly on > the to-be-freed page's buddy due to merging. > > One way to avoid this overhead is not do any merging at all for order-0 > pages and leave the need for high order pages to compaction. I think the RFC here is: we *know* this hurts high-order allocations and Aaron demonstrated that it does make the latency worse. But, unexpectedly, it didn't totally crater them. So, is the harm to large allocations worth the performance benefit afforded to smaller ones by this patch? How would we make a decision on something like that? If nothing else, this would make a nice companion topic to Daniel Jordan's "lru_lock scalability" proposal for LSF/MM. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
