Refill heuristic #511
Refill heuristic #511
Conversation
The large buddy allocator requests memory from its parent range. The request size was a fixed large request. This was sufficiently large, so that contention was not a problem. This change makes it initially smaller, and gradually growing so that contention is still not a problem, but for small work loads it requests less memory.
|
I need to do some perf testing on this to check it hasn't regressed. |
|
Did a small amount of perf testing yesterday. The worst regression was sh6bench, which only lasts a few 10s of milliseconds, so the initial contention in the warm up phase caused a big regression. From 0.08 seconds to 0.13 seconds, but the profile showed this was all in the contention for grabbing the initial memory. Many examples that use a small amount of memory per thread have dropped considerably in usage. This heuristic is probably not ideal, but it works well enough, to be an improvement. |
Modify the large buddy allocator to gradually grow its refill size up to a set amount. This is designed to work well on more limited address space platforms, but be able to grow to reduce contention on larger systems.
Primary use is for OE, where changes from CoffeeLake to IceLake mean the address space limits are very different.